Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Understanding Passkeys

michal.sapka.me

Post reply on HN
Print view View original

71–79 of 79 posts

Re: Understanding Passkeys

#71

Post by dwaite »

cmdli wrote: post #20
QhwyF3AxE wrote: post #15

Earlier quoted context omitted.

Where did you get the idea that Apple and Google's implementations are hardware-bound?

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…

> 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.

https://hachyderm.io/@rmondello/110329118270492669

Apple's existing password manager (which is what surfaces passkey management) lets you export and import the database as a CSV file, same as Google and many others. I suspect the biggest missing piece is an agreement on an interoperable format - likely one that would also be interoperable for password and TOTP exchange as well.

Re: Understanding Passkeys

#73

Post by MarkSweep »

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?

Re: Understanding Passkeys

#74

Post by acdha »

rawfan wrote: post #68
tunesmith wrote: post #25

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 id…

We‘re using a FIDO2 security key as a passkey. Corporate policies force our users to also password-protect these. So whenever people authenticate using a FIDO2 key as their passkey, they also need to enter its password. The benefit of passkeys are: - the Webapps only store a specific public key instead of a hashed password - a direct connection is necessary for the challenge/response flow so that phishing attacks or…

That last part is huge: the FIDO-2/WebAuthn protocol includes the hostname so there’s no way to have a challenge from server A get a response which could be used on server B. That alone is worth the switch since so many people get painfully phished into entering an important password on the attacker’s server.

Re: Understanding Passkeys

#75

Post by 0x457 »

zhfliz wrote: post #63
0x457 wrote: post #33

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 th…

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.

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.

Re: Understanding Passkeys

#76

Post by zhfliz »

0x457 wrote: post #75
zhfliz wrote: post #63

Earlier quoted context omitted.

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.

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.

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

Re: Understanding Passkeys

#77

Post by snagg »

cstrahan wrote: post #21
QhwyF3AxE wrote: post #15

Earlier quoted context omitted.

Where did you get the idea that Apple and Google's implementations are hardware-bound?

Per this: https://www.slashid.dev/blog/passkeys-deepdive/ The private key is both kept in your phone’s Secure Enclave and stored in iCloud, so strictly speaking the implementation isn’t hardware-bound in that case. But I think the intended point is something more practical: can you, as a user, export the passkey to be shared on your non-Apple laptop, phone, etc? And maybe I’m mistaken, but I’ve been under the impress…

Hi,

I'm the author of the blogpost. You are spot on, Passkeys are exportable so the private key ends up both on iCloud and the Enclave/authenticator.

My understanding is that there's chatter about cross-vendor synchronization of passkeys but nothing concrete yet.

Meanwhile Apple allows people to share Passkeys via AirDrop (Settings > Passwords - select the passkey you want and click the "Share" icon to send it over Airdrop) so it should be possible with some effort to obtain the private key with something like this: https://github.com/seemoo-lab/opendrop. Haven't done extensive testing yet though, so I can't confirm.

Would love to hear if anybody knows more about how the sharing via AirDrop is implemented/protected.

Re: Understanding Passkeys

#78

Post by snagg »

spear wrote: post #46
cstrahan wrote: post #21

Earlier quoted context omitted.

Per this: https://www.slashid.dev/blog/passkeys-deepdive/ The private key is both kept in your phone’s Secure Enclave and stored in iCloud, so strictly speaking the implementation isn’t hardware-bound in that case. But I think the intended point is something more practical: can you, as a user, export the passkey to be shared on your non-Apple laptop, phone, etc? And maybe I’m mistaken, but I’ve been under the impress…

I'm pretty sure my 2017 Macbook Pro (Intel, no Touch Bar) doesn't have a Secure Enclave chip, yet it supports Passkeys.

Hi,

I'm the author of the SlashID blogpost. You are right, the WebAuthn standard doesn't provide any guarantees on the authenticator storage security hence passkeys (and WebAuthn creds) can be stored in anything that speaks CTAP2.

We wrote a follow-up blogpost talking about the threat model in which we touch on the above: https://www.slashid.dev/blog/passkeys-security-implementatio...

Re: Understanding Passkeys

#79

Post by secabeen »

QhwyF3AxE wrote: post #18
secabeen wrote: post #8

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:…

> 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:…

This looks good, but it's not clear that it would actually work in this scenario. The "Recovery Security" section of the first document is good, but it requires knowledge of some combination of the phone password, an "iCloud security code", possession of the SMS number for the user, etc.

The latter two links are good, but both only refer to recovering access to an iCloud account, they don't talk about further access to escrowed iCloud keychains.

Post reply on HN