Hacker News Reader

Comment by tunesmith | Hacker News Reader

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?

View on HN

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

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

Well, we're deep into semantics now, but I think the passkey is "something you know". That you've chosen to offload your memory onto a device doesn't really change that.

But, honestly, this is a point of little importance. Almost all of the "something you..." categories are only a rough guide, and most items can arguably fall into more than one of them.

As soon as you write something down it becomes something you have.

I can't argue with that at all.

That's not really deep into semantics if it's the whole point. Something you know is by definition not externalized, and thus has a different type of security.

If a passkey is something you know then you are using a failed implementation. A fido/authn device is supposed to be able to attest to never having let the private key out, even with a relaxation to passkeys it should at least be sending it to another device that can attest.

True, but I'm hoping that "failed implementation" is accepted, because the correct implementation is too burdensome for my taste.

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 MITM are impossible (AFAIK)

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.

passkeys are often 2 factors but not necessarily something you know, examples:

- with macbook fingerprint sensor: something you have (private key on your device) and something you are (fingerprint)

- with yubikey without fingerprint: something you know (passcode, hopefully required) and something you have (private key on yubikey)

- with yubikey with fingerprint sensor: something you are (fingerprint, falling back to passcode which is something you know) and something you have (private key on yubikey)

But that's the whole point - yubikey with fingerprint, or any combination of things that exclude "something you know", opens you up to a whole set of vulnerabilities. Like "legal snooping"; that can't be done if you're protected with "something you know".

you can choose to use something you know with passkeys if preventing legal snooping is your priority.

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.

Reply on news.ycombinator.com