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

21–30 of 79 posts

Re: Understanding Passkeys

#21

Post by cstrahan »

QhwyF3AxE wrote: post #15
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…

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 impression that you cannot.

Re: Understanding Passkeys

#22

Post by cmdli »

Ciantic wrote: post #16
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…

Last time I looked into your implementation, it looks very neat, but I would like to store each passkey to a file and encrypt with GPG. I use https://www.passwordstore.org/ like mechanism to store all my passwords.

This is something that would be very nice to support, and saving to just a local file and allowing users to use their own storage mechanisms is definitely an intended use case. Right now it stores the entire vault encrypted on disk, but I would like to be able to store passkeys in a standard format (ideally supported by multiple managers) and then allow users to do whatever they want with them.

Re: Understanding Passkeys

#23

Post by byproxy »

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…

Maybe nit-picky.. but why does the Linux download assume a Debian-based distribution?

Re: Understanding Passkeys

#24

Post by cstrahan »

jmclnx wrote: post #6
psanford wrote: post #3

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

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 definitions I’ve seen, it’s the terms under which software is permitted to be shared that determines if something is proprietary or not.

Re: Understanding Passkeys

#25

Post by tunesmith »

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?

Re: Understanding Passkeys

#26

Post by mikey_p »

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…

I'd imagine access to these could still be password or bio protected, similar to current iPhone or SSH passphrase.

Re: Understanding Passkeys

#27

Post by bombcar »

mikey_p wrote: post #26
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…

I'd imagine access to these could still be password or bio protected, similar to current iPhone or SSH passphrase.

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.

Re: Understanding Passkeys

#28

Post by growse »

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.

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

Re: Understanding Passkeys

#29

Post by drdaeman »

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.

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.

Re: Understanding Passkeys

#30

Post by paulddraper »

byproxy wrote: post #23
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…

Maybe nit-picky.. but why does the Linux download assume a Debian-based distribution?

Fortunately, any non-Debian Linux uses will know enough to be to do something with the .deb.
Post reply on HN