Search code examples
authenticationpasskey

who creates the passkey (and how many will be created?)

Passkey is nice. The math is nice. The tech is nice. [web standard is a Zumutung <- ask chatgpt]

https://security.googleblog.com/2023/05/so-long-passwords-thanks-for-all-phish.html

What I still dont see:

  1. What software CREATES the passkey. User autonomy is important and it is a key question (pun intended). I do not really see this answered anywhere.

Is it the pass manager or the operating system? It should be the pass manager, since we store our secrets in a pass manager that we trust. I am not hostile to Apple, Google, Microsoft (or Linux), I use the Google Pass Manager btw. But it should be a choice and if you choose an open source pass manager (which I might in the future), it should create the key pair (and with it, the secret private key). However, it seems to me that pass managers may only get API from the os and the os creates the keys as of now. Practically as of now, 3 US companies would create all the secrets of the world in the future?

https://developer.apple.com/documentation/authenticationservices/public-private_key_authentication/supporting_passkeys

Another thing I cant get my head around:

  1. HOW MANY passkeys are INTENDED to be created. A passkey requires a pass manager. Should domain service providers (relying party) let users that do not use cross platform pass managers create passkeys on Apple, Google, Microsoft (later on Linux) and so having secrets in 4 pass managers eventually (hopefully those who do not use pass managers, now step up the game and install brutal security for all of these accounts of theirs, because it is enoguh to breach one of them).

Or the design intention is to just let them create the one and only passkey (until deletion or change) and it is the responsibility of the user (and actually AGML) that they can sync THE passkey cross platform? And how will this happen? Export, encrypted export, magic?

[Warm welcome for the question to get voted down to -4 within a minute by operators or such... I actually have researched a LOT. And asking a simple but key question may show a lot of research effort. Nobody seems to ask who CREATES the passkey (but it may be important for security and not every user is sheep material: they do understand that some secret is created for them and plenty of them want to know who creates it and who manages it. With passwords you or your pass manager creates the secret and that is really understandable. I think I managed to dig to 2 simple core questions: who should create the passkey and how the hell will it be synced for people who do not want to make the effort to invest (time,effort,money) in a truly cross platform pass manager. If and only if these 2 questions are answered and communicated(!) to users is it possible for passkeys to become a success, which would be great. And nobody talks about them anywhere!]

Update 2024-09-24:

Vow, that is something! https://blog.google/technology/safety-security/google-password-manager-passkeys-update-september-2024/

I created a minimal version of passkey registration and authentication on a web page of mine and I just played with it today (on Linux) and some strange thing came up instead of "this device is not capable blabla...": it showed my Android device, I had to sign in to my Google account, I gave my unlock PIN of the phone, and created another PIN (sorry, same...) and I think I have a totally synced ONE and only passkey!

It is a game changer, especially if Apple does the same with its new iOS18 pass manager app and Apple, Google, Microsoft let any cross platform pass manager do the same.

NOW I am considering adding passkeys to my web pages! I think the most important thing is for 99% of users that they get accustomed to the HAVING 2-3 devices and using biometrics above secure short PINs (not birthday).

You need to take care of 2 things: long, secure master pass for your pass manager (like Google account password or Apple Account password or Proton, Bitwarden etc. masterpass) and a short secure device unlock PIN (minipass).

With these, you can create accounts anywhere ONCE and access on every device, securely! If passkeys can truly support this, they will win!

Thanks for Apple and Google who seem to push this in the direction of practicality. I think the main feature is that the private key is usually much more secure than a password in bits AND you always sign a new challenge and your password is neither KNOWN to user, nor TYPED nor TRAVELS each time. No fishing, keyloggers, man in the middle etc.

Of course syncing is a trade off but security critical services can/will implement extra factors. Still Pareto-better than passwords synced for above 3 reasons.

I saw the potential, did the work, then I was disappointed and abandoned it, now I feel it is going to win. Seeing my surroundings it will take 5-10 years but device based security is the future!

Solution

  • What software CREATES the passkey. User autonomy is important and it is a key question (pun intended). I do not really see this answered anywhere.

    The passkey is created by the "authenticator". WebAuthn, the standard, doesn't care what the authenticator is. Practically it could be a security key(*) or a password manager.

    The reason that it seems like the answer might be "operating system" is that, on iOS 16 and Android 13 (the current versions at the time of writing) only iCloud Keychain or Google Password Manager (respectively) can be used to create passkeys. But this isn't fundamental and in iOS 17 and Android 14, there are APIs for other password managers to plug into passkey flows.

    HOW MANY passkeys are INTENDED to be created.

    An account typically only has one password, but it can have many passkeys. Today that's a practical necessity unless users want to pull out their phone every time they sign in because syncing doesn't work everywhere yet. But even in a world where syncing is working great, the intention is very much that users be able to register multiple passkeys if they wish and the API is designed around this: it hints when the user signed in with a phone so that the site can prompt the user to register the local device.

    (*) A passkey is supposed to sync and, if you create one on a security key, it won't sync so technically isn't a passkey. But we assume that people using security keys are expert enough to understand that and don't clutter the UI with the distinction.