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

31–40 of 79 posts

Re: Understanding Passkeys

#31

Post by judge2020 »

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…

Given it sync from iCloud, you probably could export with enough prying at the MacOS Keychain app, but exporting them out is not a supported use case yet.

Re: Understanding Passkeys

#32

Post by judge2020 »

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.

In essence it's possible - some app that exports the passkey's private key in some standard format as a QR code [per passkey], ready to be re-imported, but such import/export mechanisms haven't been made yet.

Re: Understanding Passkeys

#33

Post by 0x457 »

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.

Re: Understanding Passkeys

#34

Post by [deleted] »

throw7 wrote: post #7

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.

[deleted]

Re: Understanding Passkeys

#35

Post by shmerl »

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

Re: Understanding Passkeys

#36

Post by notatoad »

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.

Re: Understanding Passkeys

#37

Post by vbezhenar »

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…

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

Re: Understanding Passkeys

#38

Post by JohnFen »

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

Re: Understanding Passkeys

#39

Post by notatoad »

aftbit wrote: post #11

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.

i was able to use my solokey on webauthn.io with chrome on ubuntu.

Re: Understanding Passkeys

#40

Post by JohnFen »

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…

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.
Post reply on HN