7

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!]

r j
  • 186
  • 8
  • 1
    I wondered about this quite a bit too. Great question. At first the webauthn protocol was "sold" as private keys bound to devices. But this evolved in keys being synced, and from the answers it appears browsers now also enable third-party software to produce and manage these keys... what comes next? ;) ...it's also difficult to untangle the "spec" from the "browser reality" since they are "not in sync" – dagnelies Jul 19 '23 at 09:10
  • Good comment, good to know I am not the only one feeling this way. Great wording: untangle the "spec" from the "browser reality". I must add browser and os reality or rather Apple-Google-Microsoft reality since both os and browser is practically A-G-M (some linux, some firefox or brave and other chromiums). I mean the whole thingy is random ECDSA private key created and managed instead of passwords. Better against fishing but why not random 25-49 char human readable and backupable pass, where deterministically calculated ECDSA pub key is anonym user id and priv key signs a random challenge? – r j Aug 14 '23 at 11:54

3 Answers3

10

On the subject of who holds the passkey, it's important to understand that the relying party -- the site running the JavaScript navigator.credentials.create() function, has the ability to steer things in some ways.

There are 2 possibilities:

  1. Relying party specifies publicKeyCredentialCreationOptions .authenticatorSelection.authenticatorAttachment = cross-platform: The browser will require the user to plug in a "roaming authenticator", which is typically a USB key.

  2. Relying party specifies publicKeyCredentialCreationOptions .authenticatorSelection.authenticatorAttachment = platform: This is the type of attachment you're likely referring to, which is when OS (or a 3rd party app, coming soon) holds the key.

To find out more, check out the Webauthn spec. The latest editor's draft here: https://w3c.github.io/webauthn/#dictionary-authenticatorSelection contains all the documentation on the parameters above.

Edit: Removed incorrect information about the requireResidentKey param. See @agl's comment below.

nmelo
  • 169
  • 2
  • 7
  • 1
    thanks! as far as I understand, requireResidentKey = true will not enforce sync stop (apple and google sync always, NOW) it rather something like client side discoverable credentials without credential id vs. server side :https://w3c.github.io/webauthn/#client-side-discoverable-credential actually pass manager holds the passkey, my questions was who creates them :) pass managers or Apple,Google,Microsoft OS? so if you use open source pass manager, is it any protection against NSA :) – r j Jul 11 '23 at 15:05
  • if you liked the question, can you please upvote, some trolls voted it -4 just because it is not apparent that I worked a lot to come up with this question :) I am really interested in answers! as of now, I am pretty sure Apple, Google,Microsoft just gives API to pass managers where they can GET the passkey generated by THEM! I would use passkeys anyways but I want to understan WHY, has it some security rationale or just power play and NSA stuff? – r j Jul 11 '23 at 15:11
  • I find the comment nice but my 2 questions remain totally unanswered. I edited my question so that it is easier to read and discover my true questions (I tend to write verbose, I know it and I work on it every day) Thanks! – r j Jul 11 '23 at 18:12
  • 3
    "That parameter requireResidentKey is a boolean, and if set to true, indicates to the browser that the key should not be synced." requireResidentKey does not control syncing. (In fact, setting it makes it more likely that you'll get a synced credential.) It specifies that the credential is "discoverable", i.e. that it can be found without specifying its credential ID. That means that it can work without entering a username first, can appear in autocomplete, etc. – agl Jul 14 '23 at 17:06
2

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.

agl
  • 1,129
  • 5
  • 6
  • As of Aug 2023 I think it is a perfect answer. Webauthn spec says authenticator, which should be the pass manager. The browser is asked to perform passkey creation, which is bound to user verification that is performed by the OS. Would pass managers (like open source bitwarden or proton) be allowed only to store and manage, or also to create passkeys? Who controls the A-G-M OS APIs, since the spec says nothing about it. Will these APIs make third party pass managers THE authenticators, so we only have to trust our chosen pass manager? Or will they be only some receivers in this passkey flow? – r j Aug 14 '23 at 11:36
  • So pass managers should create passkeys but how many? The end product seems to be having plenty of passkeys to the same account, instead of syncing one passkey. Not that I feel it is the right way since site owners and users have to manage them too... I think it will be a mess. There could be only one passkey but there seem to be plenty of created on different platforms... well, it should be explicit that passkeys need pass managers and pass managers should be synced everywhere and just create and manage and use one passkey. Let us see what happens in the future... – r j Aug 14 '23 at 11:41
0

According to Google, it's based on the Fido2 standard, so any software compliant with that should be able to generate the keypair. The private key will typically never leave your device, unless you use some synchronization mechanism to reuse the key on other devices or otherwise take action to move it from the device.

The default mechanism for Google on Android is to use the builtin support, so while you do not have full control on the software, it all happens locally on your device.

The number of passkeys should be one for every device and account. So with 3 accounts and 4 devices you'd typically need 12 passkeys (i.e. keypairs).

Xecrets
  • 79
  • 5
  • not true, apple syncs private key within a second (without asking) to keychain and google syncs with google pass manager, it is totally synced within ecosystems (apple, google, microsoft) or will be synced and I guess they will be exportable too... of course pass manager will sync them too and keep in cloud... it happens on the device answers nothing, where else? the question is it happens within the pass manager or os (or browser but it is rather one of the former 2) both pass manager and os are on the device of course – r j Jul 11 '23 at 11:11
  • I am not sure whether webauthn standard has something to do with it... it is rather implementation, do pass managers get the info from os that local biometrics/passcode authentication was ok and they generate the key pair and store it or just get an API from apple/google/microsoft where they can get the key... seems to be a big difference to me... do 3 US companies are supposed to create the secrets of everybody in the future? – r j Jul 11 '23 at 11:23
  • @rj Concerning "not true..."- that's why I wrote "unless you use some synchronization mechanism". – Xecrets Jul 11 '23 at 16:45
  • not true that the key will typically(!) not leave your device, it may be true on microsoft because normally you have one windows pc but it typically leaves the device, in future practically 100%... I think you remember the old fido ways, but apple/google/microsoft created passkeys with explicitly sync in mind for usability... I might not have been clear but I am interested in the typical thing when people start to create passkeys with os and sync with pass manager... sorry if I was harsh, thats my style. my actual question was: who creates the passkey, sync and storage is via pass manager – r j Jul 11 '23 at 17:24