Hacker News Reader

Comment by bayindirh | Hacker News Reader

If passkey is an additional factor, I'm on the same boat with you. You can sync them all the way down.

But if it's the only factor, I can't see a difference between password reuse and passkey reuse. If I can recover it in any way, then it's (very) game over.

So I'm not mad that you can't sync a passkey if it's the single factor. Because as we don't reuse app passwords for multiple devices or normal passwords for multiple sites, we shouldn't use the same private keys on many devices, allowing a more granular and better approach.

Of course this is my view and some people won't agree. I prefer a good multi-layer system, not a single passkey opens the whole world style one.

View on HN

Why do you think it is reuse?

You will not use the same passkey for multiple application/service.

You will generate a passkey per application/service.

I will certainly though not disagree on security... if that is your thing then do not sync private keys around, but the tradeoff is always there. If security would be critical, I would favor client certs with smartcards, but browsers do not support that "too well"

If I share the same private key for an account with "n" devices, losing (incl. theft of) that key will lock me out.

If I have "n" private keys for an account, I can use another private key and revoke the lost/compromised one. It's that simple.

Your secure enclave is not much different electronically from a smart card with a biometric password actually. People think Passkeys as SSH keys on disk, but it's more of a long private key on a single-way secure enclave. This is why people cry "platform lock-in". It's platform lock-in, but it's a secondary effect. It's actually a "proper HSM, but integrated".

Yes but the same logic about loosing the secret applies to passwords and any other factors (given we ignore a potential reset process)

Providers will most of the time allow to register multiple passkeys or other authentication means, hopefully ;-) which has its own downsides.

I am well aware how the internals work of keystores. But the benefit with "client certs" is that on mTLS you get added benefits besides where the key is stored. And that is that you can "prevent" mitm attacks.

But I guess that is a subject for another thread.

Resident passkeys really are just the 2020-JavaScript version of X.509-based mutual authentication - naturally it's incompatible with anything but the web, sits on a weird level of the stack, and is somehow even less transparent to the user. On the other hand, certificate slots still seem to run approximately a dollar each.

Haha comparison made me giggle.

When using a passkey as the only factor, it gets complicated, but I think that will be the future: Email and SMS as fallbacks with additional factors like risk-based location checks (or local storage hints) to have a viable recovery mechanism parallel to passkeys. I think Github has a nice approach that we use as a role model: Collect as many fallbacks as possible in a convenient manner. Adding passkeys on any new device and regularly reminding people to check their fallbacks. That's still way more secure than passwords only, where the fallback is practically always a form of email OTP. Also social logins from Google or Apple can act as a fallback as they are (mostly) 2FA.

I'm not against using a passkey as a single factor, and having fallbacks. It's reasonable if you can reliably attach that key to a physical device, so the device can't be impersonated.

I don't think that we should target MIL-xxx standards for daily use, but my security is comparably important to me as military's missile codes are important to them.

So, I don't want my passkey-based services to have a security theater in the name of convenience. There should be some friction to force a baseline security.

Agree, but I think in a B2C context, you need convenience first; then security can follow.

I think it depends. Banking, primary e-mails, etc. are extremely important systems today, and they should bias towards security. Other platforms where we talk can take a more balanced approach, and more casual sites can lean towards convenience, if you ask me.

Indeed, the problem with lots of fallbacks is that they can invalidate user's requests for higher security. Security can sometimes end up being only as strong as the weakest link.

Make the fallback too lax and you might as well not bother with 2FA/Passkeys at all.

Reply on news.ycombinator.com