8 ms·

Understanding Passkeys

92 points by d-s 3y ago

shmerl 3y ago
> I am waiting for an open solution that will give me the authority to manage and sync passkeys. Exactly. Hopefully kepassxc will have that as well and it will be possible to use when needed.
dang 3y ago
Recent and related: Passage by 1Password: Add passkey support to your app or website - https://news.ycombinator.com/item?id=35988348 https://news.ycombinator.com/item?id=35988348 - May 2023 (114 comments)
- lapcat 3y ago
  Also: Passkeys: A Loss of User Control? - https://news.ycombinator.com/item?id=35854216 https://news.ycombinator.com/item?id=35854216 - May 2023 (175 comments)
psanford 3y ago
> ...I’d much prefer GNU Pass to support it Nit: Pass[0] is not a GNU project. [0]: https://www.passwordstore.org/ https://www.passwordstore.org/
- d-s 3y ago
  Thanks!
- jmclnx 3y ago
  Good to know, I would trust GNU as opposed to a proprietary solution.
  - cstrahan 3y ago
    Are you implying Pass is proprietary? In case clarification is needed: Pass is GPL licensed, open source software. GPL is not the same as the GNU Project. The former is a license; the latter is collaborative project composed of multiple software packages and their respective contributors, typically using the GPL license. I fail to see how the authorship of a project makes something (non)proprietary — in all definitions I’ve seen, it’s the terms under which software is permitted to be shared that determines if something is proprietary or not.
    - jmclnx 3y ago
      I could not get into the article, so since open that is fine.
throw7 3y ago
Is it the _goal_ of FIDO to get rid of passwords? If it is, I am against this industry group. Passwords should always be kept as a valid authentication method. The OP brings up a point about not having access to the private key... I agree with that. If I don't have access to the private key (like I currently do with ssh) then it's dead in the water to me.
- cyberax 3y ago
  With passkeys the private keys are accessible. They have to be, because they need to be synced across devices. The OS will try to protect these keys by putting them in a protected process, with all kinds of safeguards. But in the end, the private keys will still be available. FIDO also supports device authenticators, where the private key (by design) never leaves the hardware. These devices can be used for the true 2FA.
- growse 3y ago
  > Passwords should always be kept as a valid authentication method Why? > If I don't have access to the private key (like I currently do with ssh) then it's dead in the water to me. You don't have 'access' to the private key for any well designed HSM either. And there's nothing in the passkey spec that says you need to put the private key in at inaccessible place.
  - effie 3y ago
    > Why? Because access by password provides unique abilities to the person who knows the password.
- drdaeman 3y ago
  How losing a private key is different from losing a password? Memorable passwords should be either an exception (like master passwords) or a device-specific thing. And private keys do not have to be locked to a HSM. If this really matters, private keys can also be memorized if they were derived by a KDF, using a seed phrase.
- deleted 3y ago
  [deleted]
secabeen 3y ago
Is there any company actually providing anything resembling emergency access for Passkeys? A critical feature of password vaults for me is the ability of my heirs to get access to my passwords when I am incapacitated or dead. I can't print out my passkeys and store them in a safe, nor does there appear to be any system for allowing someone access to my passkeys. Features like this seem like table-stakes to me: https://www.lastpass.com/features/emergency-access https://www.lastpass.com/features/emergency-access
- cyberax 3y ago
  In practice, as long as your heirs have access to your email, they should be OK. Password reset flows still work with passkeys. You also should be able to back up passkeys onto a flash drive and encrypt them with a strong password. I don't think there's a good tooling for this right now, though. On macOS you'll need to go to Keychain Access and manually export the keys. (I store everything important in an encrypted container, with the 128-bit recovery code printed on paper and stored in a safe deposit box)
- ezfe 3y ago
  At least with 1Password an export contains Passkeys, and Safari team has indicated the same will be available.
- QhwyF3AxE 3y ago
  > I can't print out my passkeys and store them in a safe, nor does there appear to be any system for allowing someone access to my passkeys. Recovery is handled differently depending on who you are using to sync your passkeys. Apple has a great recovery story. iCloud Keychain supports both a "recovery key" and "recovery contacts". See the section titled "Recovery security" in the "About the security of passkeys" doc: https://support.apple.com/en-us/HT213305 https://support.apple.com/en-us/HT213305 Additional relevant docs: Recovery contact: https://support.apple.com/en-us/HT212513 https://support.apple.com/en-us/HT212513 Recovery key: https://support.apple.com/en-us/HT208072 https://support.apple.com/en-us/HT208072
  - secabeen 3y ago
cmdli 3y ago
Just because this is a common misunderstanding of passkeys, I'm going to state it again here: passkeys don't have to be locked to a hardware chip inside your device in order to work. It is entirely possible to have use passkeys only in software (shameless plug to the passkey manager I'm building, https://bulwark.id https://bulwark.id), and that is most likely the way that most people will interact with them. I think it's unfortunate that Apple and Google are the ones who are most visible in the passkey space because it gives people the idea that passkeys are a locked-down authentication mechanism when they aren't.
- byproxy 3y ago
  Maybe nit-picky.. but why does the Linux download assume a Debian-based distribution?
  - paulddraper 3y ago
    Fortunately, any non-Debian Linux uses will know enough to be to do something with the .deb.
- QhwyF3AxE 3y ago
  Where did you get the idea that Apple and Google's implementations are hardware-bound?
  - cmdli 3y ago
    Generally, the idea is that the private keys are stored on a TPM chip so they cannot be exported for security reasons, similar to a YubiKey or a crypto wallet. I know Apple and Google are looking into trying to allow users to somehow export these keys elsewhere, but I'm uncertain how easy that will be or what tradeoffs there will be. I'm skeptical that Apple and Google will try to make it too easy since they benefit from user lock-in, but I would be happy to be proven wrong.
    - lukeschlather 3y ago
      As far as I can tell both Google and Apple have a mechanism to export the key so you can replicate the same key to another device. I run into this same situation with "HSM clusters" sold in enterprises where I don't really understand how people can claim with a straight face that you can't export the key to another device when they just explained to me that they export the key to another device.
aftbit 3y ago
Apparently these are unsupported on Linux? When I try to use my brand new Yubikey 5 Nano with Chrome or Firefox on the webauthn.io demo, it works great. However when I try on passkeys.io, it just hangs at the "You can connect and authorize [a security key] now" prompt.
- cmdli 3y ago
  I've been working on passkeys for about a year now, and from my experience passkey support is fairly inconsistent. Every website+browser+OS combination can do things slightly differently or ask for a different set of features from the authenticator (some require PIN support, some require certain flags, etc), so the experience can be a bit buggy. I imagine that as passkeys get more common the support from authenticators and platforms will improve as it becomes more standardized.
- notatoad 3y ago
  i was able to use my solokey on webauthn.io with chrome on ubuntu.
ryukafalz 3y ago
> The Client Device should sign the sent public key with its own Attestation Certificate. The certificate is used to attest to the manufacturer and its capabilities. A nitpick: should is a value judgment here. Quite a few of us would rather they do not, to avoid websites taking advantage of this to require specific proprietary hardware to authenticate. Thankfully my understanding is that Apple's passkeys do not provide attestation, which is likely to make this kind of hardware requirement uncommon.
- JohnFen 3y ago
  Yes, I consider attestation a bit of a poison pill, personally. I'm very ambivalent about passkeys as it is, if attestation throws a monkey wrench into the works, my ambivalence would become active resistance.
- woodruffw 3y ago
  > Apple's passkeys do not provide attestation Apple has their own anonymous attestation format[1] that some (unclear which?) of their WebAuthn authenticators support. In principle the relying party could use this to verify the authenticity of the authenticator back up to Apple's WebAuthn root CA[2]. In practice, I'm not sure if that attestation is included by default (or whether significant portions of users opt out of it, when prompted by their browser). [1]: https://github.com/w3c/webauthn/pull/1491 https://github.com/w3c/webauthn/pull/1491 [2]: https://www.apple.com/certificateauthority/Apple_WebAuthn_Root_CA.pem https://www.apple.com/certificateauthority/Apple_WebAuthn_Ro...
- sowbug 3y ago
  It makes sense in an enterprise context, where the company might want to make sure no employee clones a client device key. In that case, they would require remote attestation to authorize only private keys living in secure elements (and thus less accessible to the employee).
cyberax 3y ago
TLDR; version: 1. With passkeys/WebAuthn you simply use private keys to authenticate. Almost exactly like with SSH keys, except that the keys are site-specific. 2. WebAuthn supports using hardware devices for 2FA, where the private key never leaves the authenticator device. 3. Passkeys are not like this. With passkeys, the private keys are managed by the OS and are synced across multiple devices. The OS has direct access to them, and so it's possible to extract these keys and do whatever you want with them.
tunesmith 3y ago
I'm just confused about the "something-you-know" aspect of this. From my understanding, in the US you can be legally forced to give your fingerprint, face scan, probably your retina scan, maybe your voice identification... these are all "things you have", more akin to "username". But a password is the "thing you know", the thing they can't take from you (discussions of torture and AI mind-reading aside). So is the idea there that that basically goes away with passkeys, and that your only "thing-you-know" protection is the x-digit passcode you punch into your phone?
- mikey_p 3y ago
  I'd imagine access to these could still be password or bio protected, similar to current iPhone or SSH passphrase.
  - bombcar 3y ago
    The iPhone very particularly insists on a password/passcode if you trigger the emergency call screen, so that you can do that quickly and they can't force you to unlock biometrical.
- JohnFen 3y ago
  > fingerprint, face scan, probably your retina scan, maybe your voice identification Technically, those are "things you are", not "things you have". A Yubikey would be an example of a "thing you have". I think the ideal is that you're supposed to use a hardware key that uses a biometric like a fingerprint to unlock it. Then the passkey itself is the "thing you know", the hardware key is the "thing you have", and the fingerprint is the "thing you are". But in practice, that's pretty onerous, so the passkey implementation being discussed eases up on those requirements a bit.
  - lukeschlather 3y ago
    A passkey is never a "thing you know." It is a "thing you have access to, which mostly behaves like a 'thing you have' but also your OS provider probably has it if they want it."
0x457 3y ago
I always thought Passkeys is: Workflow for applications that aren't web applications. WebauthN only works in a browser, while passkeys work in "other" types of applications. The fact that the private key is stored on iCloud is mostly irrelevant for understanding how it works, that's a client device implementation detail. There are software-only authenticators that work with WebauthN just fine and allow you to back them up.
- zhfliz 3y ago
  webauthn can very much be used in a desktop application, you're just losing the phishing resistance factor, as the application can choose what to send as identifier, which includes collecting tokens for other tools/websites.
  - 0x457 3y ago
    Well, you can use webauthn in a desktop application by opening a browser. I'm annoyed to do it every time I have authenticated with Bitwarden.
    - zhfliz 3y ago
      you can also use it natively in non-browser applications. just the other day i've used it in a CLI application (which authenticated against web, but without real browser): https://github.com/Yubico/python-fido2 https://github.com/Yubico/python-fido2
cxmcc 3y ago
The article said Apple/Google tries to become the guardians of private key. That isn't true according to my understanding. Private key can stay on private devices owned by the user and never leaves the devices.
woodruffw 3y ago
A note on attestation, since that's a part of Passkeys (and Webauthn) that's frequently misunderstood: WebAuthn has a broad understanding of "attestation," including "self attestations"[1] and no attestations at all[2]. To the best of my knowledge, Passkeys do not impose any further constraints on attestations, meaning that compliant authenticators don't need to send any attestation at all. Relying parties can of course reject authenticators for any reason, including for not having an attestation statement (or not having one from a particular vendor). In practice, I'm not aware of any major public service that does that: actually verifying vendor attestations introduces yet another PKI, and has dubious security benefits outside of corporate (meaning fixed hardware) contexts. In other words: while understandable, I think a lot of concern about vendor lock-in and lock-out are pretty overblown. There's no indication that services like GitHub will even find attestation handling feasible, much less desirable. [1]: https://www.w3.org/TR/webauthn/#self-attestation https://www.w3.org/TR/webauthn/#self-attestation [2]: https://www.w3.org/TR/webauthn/#none https://www.w3.org/TR/webauthn/#none
- JohnFen 3y ago
  My worry about attestation isn't that it will lead to vendor lock-in, it's that some services may choose to reject authenticators that don't attest that they're storing the keys in TPM or similar.
dannyisaphantom 3y ago
On my Windows laptop, I was able to set up a passkey with Windows Hello [a fingerprint swipe] to get into a secondary Google account that really only exists to store [pages of] coloring books (PDFs) I'm admittedly ignorant in this domain; but I thought it was interesting that my built-in Chrome passwords were, and still are, locked behind the Windows Hello pop-up and now I could theoretically use that same mechanism to sign in to a google account all together. The answer is probably in this article but I just don't understand; I'd love to know why Windows Hello can now be used to sign-in to the account. Probably won't use it in favor of an authenticator app. Suppose I should do a test to see how passkey behaves for the account on a Windows laptop and how that will then work on a Chromebook...
tsone 3y ago
If your a developer, you would probably want to minimize setup time with sth like https://corbado.com https://corbado.com
tdeck 3y ago
So, it's like two factor, but without the first factor?
deleted 3y ago
[deleted]
rstuart4133 3y ago
Looks like the OP tried to simplify things, but I think he's takes it too far. No mention of how FIDO preserves privacy, or how WebAuthn works with the browser protect against phishing. It doesn't get much beyond saying it's a protocol based on a public / private key pair. Perhaps that is fair enough because his problem seems to be on how that private / public key pair is managed, as evidenced by his comment at the end:"I am waiting for an open solution that will give me the authority to manage and sync passkeys". But if you make Joe Citizen responsible for the protection of the private key, you will end up with plain text copies of it everywhere. That doesn't look like a workable solution to me - it's barely better than passwords. WebAuthn went to the other extreme - it seemed to built on assumption the private key was stored in a hardware token and could not be copied. But that meant your ID died when the token was lost or broke. In effect in WebAuthn the private key was so well protected it also wasn't a workable solution. (Actually, they had a published solution to the lost token problem - you kept multiple tokens, and authenticated with every site with all of them. I don't know why they though that was going to fly.) Passkey is somewhere between those two extremes - companies with a track record in protecting private data keep a copy, and manage the transfer between secure repositories. It's a step down in security, because you how have to trust the company not to leak it. But to be fair, I'd trust Google's ability to keep it secure more than I'd trust myself. You also have to trust the company to not give copies to devices that could leak it. So far they only seem to be trusting phones they make, which is a big restriction but is understandable. I can live with those compromises. I'm not so OK with "if Google deletes my account, I lose my key". They are talking of allowing the transfer of the private key to other companies. Google giving a copy Apple is an obvious example, as it would lets you transfer your ID from Android to iOS. But so far it's only talk. And if they continue to insist only a phone they control can be trusted to store the key then even if they do allow transfer it still leaves you with just two key minding providers - Apple and Google. I don't know what to do about that. You can't trust any machine that lets the user have sudo access (or in general change the software) - so Windows and the traditional Linux desktop is out. (Obviously Linux itself and open source in general is fine - Android is Linux after all. The issue is Linux desktops give their users sudo and then by extension any malware that gets in the ability to change/access anything - including the private key.) Perhaps they might allow transfer to other dedicated tokens. A totally open source token that doesn't support firmware upgrades would work. In any case the key management problem is complex. Damned complex. The "just make the user responsible for key management" throw away at the end of the OP is never going to fly. It's a simple solution to a complex problem - and it's wrong. The reason we are in this mess state now isn't because Google/Apple are trying to lock you in - it's because there are trying to provide something that works for most people, and there are no easy/fast easy solutions.
deleted 3y ago
[deleted]
MarkSweep 3y ago
Is there any key revocation or rotation mechanism for passkeys? Like if somehow my private key leaks, can I revoke it so it can’t be used to login? Or do I have to log into every site and revoke my old key and add a new one?

92 points by d-s 3y ago

> I am waiting for an open solution that will give me the authority to manage and sync passkeys. Exactly. Hopefully kepassxc will have that as well and it will be possible to use when needed.

dang 3y ago

Recent and related: Passage by 1Password: Add passkey support to your app or website - https://news.ycombinator.com/item?id=35988348 https://news.ycombinator.com/item?id=35988348 - May 2023 (114 comments)

lapcat 3y ago
Also: Passkeys: A Loss of User Control? - https://news.ycombinator.com/item?id=35854216 https://news.ycombinator.com/item?id=35854216 - May 2023 (175 comments)

psanford 3y ago

> ...I’d much prefer GNU Pass to support it Nit: Pass[0] is not a GNU project. [0]: https://www.passwordstore.org/ https://www.passwordstore.org/

d-s 3y ago
Thanks!
jmclnx 3y ago
Good to know, I would trust GNU as opposed to a proprietary solution.
- cstrahan 3y ago
  Are you implying Pass is proprietary? In case clarification is needed: Pass is GPL licensed, open source software. GPL is not the same as the GNU Project. The former is a license; the latter is collaborative project composed of multiple software packages and their respective contributors, typically using the GPL license. I fail to see how the authorship of a project makes something (non)proprietary — in all definitions I’ve seen, it’s the terms under which software is permitted to be shared that determines if something is proprietary or not.
  - jmclnx 3y ago
    I could not get into the article, so since open that is fine.

throw7 3y ago

Is it the _goal_ of FIDO to get rid of passwords? If it is, I am against this industry group. Passwords should always be kept as a valid authentication method. The OP brings up a point about not having access to the private key... I agree with that. If I don't have access to the private key (like I currently do with ssh) then it's dead in the water to me.

cyberax 3y ago
With passkeys the private keys are accessible. They have to be, because they need to be synced across devices. The OS will try to protect these keys by putting them in a protected process, with all kinds of safeguards. But in the end, the private keys will still be available. FIDO also supports device authenticators, where the private key (by design) never leaves the hardware. These devices can be used for the true 2FA.
growse 3y ago
> Passwords should always be kept as a valid authentication method Why? > If I don't have access to the private key (like I currently do with ssh) then it's dead in the water to me. You don't have 'access' to the private key for any well designed HSM either. And there's nothing in the passkey spec that says you need to put the private key in at inaccessible place.
- effie 3y ago
  > Why? Because access by password provides unique abilities to the person who knows the password.
drdaeman 3y ago
How losing a private key is different from losing a password? Memorable passwords should be either an exception (like master passwords) or a device-specific thing. And private keys do not have to be locked to a HSM. If this really matters, private keys can also be memorized if they were derived by a KDF, using a seed phrase.
deleted 3y ago
[deleted]

secabeen 3y ago

Is there any company actually providing anything resembling emergency access for Passkeys? A critical feature of password vaults for me is the ability of my heirs to get access to my passwords when I am incapacitated or dead. I can't print out my passkeys and store them in a safe, nor does there appear to be any system for allowing someone access to my passkeys. Features like this seem like table-stakes to me: https://www.lastpass.com/features/emergency-access https://www.lastpass.com/features/emergency-access

cyberax 3y ago
In practice, as long as your heirs have access to your email, they should be OK. Password reset flows still work with passkeys. You also should be able to back up passkeys onto a flash drive and encrypt them with a strong password. I don't think there's a good tooling for this right now, though. On macOS you'll need to go to Keychain Access and manually export the keys. (I store everything important in an encrypted container, with the 128-bit recovery code printed on paper and stored in a safe deposit box)
ezfe 3y ago
At least with 1Password an export contains Passkeys, and Safari team has indicated the same will be available.
QhwyF3AxE 3y ago
> I can't print out my passkeys and store them in a safe, nor does there appear to be any system for allowing someone access to my passkeys. Recovery is handled differently depending on who you are using to sync your passkeys. Apple has a great recovery story. iCloud Keychain supports both a "recovery key" and "recovery contacts". See the section titled "Recovery security" in the "About the security of passkeys" doc: https://support.apple.com/en-us/HT213305 https://support.apple.com/en-us/HT213305 Additional relevant docs: Recovery contact: https://support.apple.com/en-us/HT212513 https://support.apple.com/en-us/HT212513 Recovery key: https://support.apple.com/en-us/HT208072 https://support.apple.com/en-us/HT208072
- secabeen 3y ago

cmdli 3y ago

Just because this is a common misunderstanding of passkeys, I'm going to state it again here: passkeys don't have to be locked to a hardware chip inside your device in order to work. It is entirely possible to have use passkeys only in software (shameless plug to the passkey manager I'm building, https://bulwark.id https://bulwark.id), and that is most likely the way that most people will interact with them. I think it's unfortunate that Apple and Google are the ones who are most visible in the passkey space because it gives people the idea that passkeys are a locked-down authentication mechanism when they aren't.

byproxy 3y ago
Maybe nit-picky.. but why does the Linux download assume a Debian-based distribution?
- paulddraper 3y ago
  Fortunately, any non-Debian Linux uses will know enough to be to do something with the .deb.
QhwyF3AxE 3y ago
Where did you get the idea that Apple and Google's implementations are hardware-bound?
- cmdli 3y ago
  Generally, the idea is that the private keys are stored on a TPM chip so they cannot be exported for security reasons, similar to a YubiKey or a crypto wallet. I know Apple and Google are looking into trying to allow users to somehow export these keys elsewhere, but I'm uncertain how easy that will be or what tradeoffs there will be. I'm skeptical that Apple and Google will try to make it too easy since they benefit from user lock-in, but I would be happy to be proven wrong.
  - lukeschlather 3y ago
    As far as I can tell both Google and Apple have a mechanism to export the key so you can replicate the same key to another device. I run into this same situation with "HSM clusters" sold in enterprises where I don't really understand how people can claim with a straight face that you can't export the key to another device when they just explained to me that they export the key to another device.

aftbit 3y ago

Apparently these are unsupported on Linux? When I try to use my brand new Yubikey 5 Nano with Chrome or Firefox on the webauthn.io demo, it works great. However when I try on passkeys.io, it just hangs at the "You can connect and authorize [a security key] now" prompt.

cmdli 3y ago
I've been working on passkeys for about a year now, and from my experience passkey support is fairly inconsistent. Every website+browser+OS combination can do things slightly differently or ask for a different set of features from the authenticator (some require PIN support, some require certain flags, etc), so the experience can be a bit buggy. I imagine that as passkeys get more common the support from authenticators and platforms will improve as it becomes more standardized.
notatoad 3y ago
i was able to use my solokey on webauthn.io with chrome on ubuntu.

ryukafalz 3y ago

> The Client Device should sign the sent public key with its own Attestation Certificate. The certificate is used to attest to the manufacturer and its capabilities. A nitpick: should is a value judgment here. Quite a few of us would rather they do not, to avoid websites taking advantage of this to require specific proprietary hardware to authenticate. Thankfully my understanding is that Apple's passkeys do not provide attestation, which is likely to make this kind of hardware requirement uncommon.

JohnFen 3y ago
Yes, I consider attestation a bit of a poison pill, personally. I'm very ambivalent about passkeys as it is, if attestation throws a monkey wrench into the works, my ambivalence would become active resistance.
woodruffw 3y ago
> Apple's passkeys do not provide attestation Apple has their own anonymous attestation format[1] that some (unclear which?) of their WebAuthn authenticators support. In principle the relying party could use this to verify the authenticity of the authenticator back up to Apple's WebAuthn root CA[2]. In practice, I'm not sure if that attestation is included by default (or whether significant portions of users opt out of it, when prompted by their browser). [1]: https://github.com/w3c/webauthn/pull/1491 https://github.com/w3c/webauthn/pull/1491 [2]: https://www.apple.com/certificateauthority/Apple_WebAuthn_Root_CA.pem https://www.apple.com/certificateauthority/Apple_WebAuthn_Ro...
sowbug 3y ago
It makes sense in an enterprise context, where the company might want to make sure no employee clones a client device key. In that case, they would require remote attestation to authorize only private keys living in secure elements (and thus less accessible to the employee).

cyberax 3y ago

TLDR; version: 1. With passkeys/WebAuthn you simply use private keys to authenticate. Almost exactly like with SSH keys, except that the keys are site-specific. 2. WebAuthn supports using hardware devices for 2FA, where the private key never leaves the authenticator device. 3. Passkeys are not like this. With passkeys, the private keys are managed by the OS and are synced across multiple devices. The OS has direct access to them, and so it's possible to extract these keys and do whatever you want with them.

tunesmith 3y ago

I'm just confused about the "something-you-know" aspect of this. From my understanding, in the US you can be legally forced to give your fingerprint, face scan, probably your retina scan, maybe your voice identification... these are all "things you have", more akin to "username". But a password is the "thing you know", the thing they can't take from you (discussions of torture and AI mind-reading aside). So is the idea there that that basically goes away with passkeys, and that your only "thing-you-know" protection is the x-digit passcode you punch into your phone?

mikey_p 3y ago
I'd imagine access to these could still be password or bio protected, similar to current iPhone or SSH passphrase.
- bombcar 3y ago
  The iPhone very particularly insists on a password/passcode if you trigger the emergency call screen, so that you can do that quickly and they can't force you to unlock biometrical.
JohnFen 3y ago
> fingerprint, face scan, probably your retina scan, maybe your voice identification Technically, those are "things you are", not "things you have". A Yubikey would be an example of a "thing you have". I think the ideal is that you're supposed to use a hardware key that uses a biometric like a fingerprint to unlock it. Then the passkey itself is the "thing you know", the hardware key is the "thing you have", and the fingerprint is the "thing you are". But in practice, that's pretty onerous, so the passkey implementation being discussed eases up on those requirements a bit.
- lukeschlather 3y ago
  A passkey is never a "thing you know." It is a "thing you have access to, which mostly behaves like a 'thing you have' but also your OS provider probably has it if they want it."

0x457 3y ago

I always thought Passkeys is: Workflow for applications that aren't web applications. WebauthN only works in a browser, while passkeys work in "other" types of applications. The fact that the private key is stored on iCloud is mostly irrelevant for understanding how it works, that's a client device implementation detail. There are software-only authenticators that work with WebauthN just fine and allow you to back them up.

zhfliz 3y ago
webauthn can very much be used in a desktop application, you're just losing the phishing resistance factor, as the application can choose what to send as identifier, which includes collecting tokens for other tools/websites.
- 0x457 3y ago
  Well, you can use webauthn in a desktop application by opening a browser. I'm annoyed to do it every time I have authenticated with Bitwarden.
  - zhfliz 3y ago
    you can also use it natively in non-browser applications. just the other day i've used it in a CLI application (which authenticated against web, but without real browser): https://github.com/Yubico/python-fido2 https://github.com/Yubico/python-fido2

cxmcc 3y ago

The article said Apple/Google tries to become the guardians of private key. That isn't true according to my understanding. Private key can stay on private devices owned by the user and never leaves the devices.

woodruffw 3y ago

A note on attestation, since that's a part of Passkeys (and Webauthn) that's frequently misunderstood: WebAuthn has a broad understanding of "attestation," including "self attestations"[1] and no attestations at all[2]. To the best of my knowledge, Passkeys do not impose any further constraints on attestations, meaning that compliant authenticators don't need to send any attestation at all. Relying parties can of course reject authenticators for any reason, including for not having an attestation statement (or not having one from a particular vendor). In practice, I'm not aware of any major public service that does that: actually verifying vendor attestations introduces yet another PKI, and has dubious security benefits outside of corporate (meaning fixed hardware) contexts. In other words: while understandable, I think a lot of concern about vendor lock-in and lock-out are pretty overblown. There's no indication that services like GitHub will even find attestation handling feasible, much less desirable. [1]: https://www.w3.org/TR/webauthn/#self-attestation https://www.w3.org/TR/webauthn/#self-attestation [2]: https://www.w3.org/TR/webauthn/#none https://www.w3.org/TR/webauthn/#none

JohnFen 3y ago
My worry about attestation isn't that it will lead to vendor lock-in, it's that some services may choose to reject authenticators that don't attest that they're storing the keys in TPM or similar.

dannyisaphantom 3y ago

On my Windows laptop, I was able to set up a passkey with Windows Hello [a fingerprint swipe] to get into a secondary Google account that really only exists to store [pages of] coloring books (PDFs) I'm admittedly ignorant in this domain; but I thought it was interesting that my built-in Chrome passwords were, and still are, locked behind the Windows Hello pop-up and now I could theoretically use that same mechanism to sign in to a google account all together. The answer is probably in this article but I just don't understand; I'd love to know why Windows Hello can now be used to sign-in to the account. Probably won't use it in favor of an authenticator app. Suppose I should do a test to see how passkey behaves for the account on a Windows laptop and how that will then work on a Chromebook...

tsone 3y ago

If your a developer, you would probably want to minimize setup time with sth like https://corbado.com https://corbado.com

tdeck 3y ago

So, it's like two factor, but without the first factor?

deleted 3y ago

[deleted]

rstuart4133 3y ago

Looks like the OP tried to simplify things, but I think he's takes it too far. No mention of how FIDO preserves privacy, or how WebAuthn works with the browser protect against phishing. It doesn't get much beyond saying it's a protocol based on a public / private key pair. Perhaps that is fair enough because his problem seems to be on how that private / public key pair is managed, as evidenced by his comment at the end:"I am waiting for an open solution that will give me the authority to manage and sync passkeys". But if you make Joe Citizen responsible for the protection of the private key, you will end up with plain text copies of it everywhere. That doesn't look like a workable solution to me - it's barely better than passwords. WebAuthn went to the other extreme - it seemed to built on assumption the private key was stored in a hardware token and could not be copied. But that meant your ID died when the token was lost or broke. In effect in WebAuthn the private key was so well protected it also wasn't a workable solution. (Actually, they had a published solution to the lost token problem - you kept multiple tokens, and authenticated with every site with all of them. I don't know why they though that was going to fly.) Passkey is somewhere between those two extremes - companies with a track record in protecting private data keep a copy, and manage the transfer between secure repositories. It's a step down in security, because you how have to trust the company not to leak it. But to be fair, I'd trust Google's ability to keep it secure more than I'd trust myself. You also have to trust the company to not give copies to devices that could leak it. So far they only seem to be trusting phones they make, which is a big restriction but is understandable. I can live with those compromises. I'm not so OK with "if Google deletes my account, I lose my key". They are talking of allowing the transfer of the private key to other companies. Google giving a copy Apple is an obvious example, as it would lets you transfer your ID from Android to iOS. But so far it's only talk. And if they continue to insist only a phone they control can be trusted to store the key then even if they do allow transfer it still leaves you with just two key minding providers - Apple and Google. I don't know what to do about that. You can't trust any machine that lets the user have sudo access (or in general change the software) - so Windows and the traditional Linux desktop is out. (Obviously Linux itself and open source in general is fine - Android is Linux after all. The issue is Linux desktops give their users sudo and then by extension any malware that gets in the ability to change/access anything - including the private key.) Perhaps they might allow transfer to other dedicated tokens. A totally open source token that doesn't support firmware upgrades would work. In any case the key management problem is complex. Damned complex. The "just make the user responsible for key management" throw away at the end of the OP is never going to fly. It's a simple solution to a complex problem - and it's wrong. The reason we are in this mess state now isn't because Google/Apple are trying to lock you in - it's because there are trying to provide something that works for most people, and there are no easy/fast easy solutions.

deleted 3y ago

[deleted]

MarkSweep 3y ago

Is there any key revocation or rotation mechanism for passkeys? Like if somehow my private key leaks, can I revoke it so it can’t be used to login? Or do I have to log into every site and revoke my old key and add a new one?