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

41–50 of 79 posts

Re: Understanding Passkeys

#41

Post by michaelt »

vbezhenar wrote: post #37
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…

If macOS can download it from iCloud, with enough reverse engineering you should be able to use the same APIs.

Unless iCloud only lets you download it in a form only the secure enclave can decrypt.

Re: Understanding Passkeys

#42

Post by lukeschlather »

JohnFen wrote: post #38
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…

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

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

Re: Understanding Passkeys

#43

Post by lukeschlather »

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…

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.

Re: Understanding Passkeys

#44

Post by dvzk »

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…

That is not Apple’s stated design at all. If you read Apple’s passkeys security document, it claims that the private keys are synchronized with iCloud and are recoverable following the loss of all devices. Non-exportable passkeys using the TPM is an HN myth.

Re: Understanding Passkeys

#45

Post by SahAssar »

notatoad wrote: post #36
cmdli wrote: post #9

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 ), and that is most likely the way that most people will interact with them. I think it's unfortunate t…

>that is most likely the way that most people will interact with them i admire your confidence in your product, but i'm pretty sure the way most users will interact with passkeys is the first-party workflow that their devices promote, and not third-party tools.

Just lite the most common password manager is the one built into chrome and ios, right?

Re: Understanding Passkeys

#46

Post by spear »

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…

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

Re: Understanding Passkeys

#47

Post by woodruffw »

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

[2]: https://www.w3.org/TR/webauthn/#none

Re: Understanding Passkeys

#48

Post by cxmcc »

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.

Re: Understanding Passkeys

#49

Post by woodruffw »

ryukafalz wrote: post #17

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

> 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

[2]: https://www.apple.com/certificateauthority/Apple_WebAuthn_Ro...

Re: Understanding Passkeys

#50

Post by jmclnx »

cstrahan wrote: post #24
jmclnx wrote: post #6

Earlier quoted context omitted.

Good to know, I would trust GNU as opposed to a proprietary solution.

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

I could not get into the article, so since open that is fine.
Post reply on HN