Hacker News Reader

Comment by Aardwolf | Hacker News Reader

Plus many want your phone number or some random app by them on your phone for their 2FA (instead of e.g. TOTP that you contol), less secure because they now can leak your phone number or do something with an update to the app

BTW what's the sentiment on passkeys?

View on HN

In my opinion passkeys, whilst solving the password related issues, introduce their own. The risk of losing access to your accounts is greater if you tie everything to one device and that's lost or stolen, and the "solution" to use more than one device is not a solution, or feasible for everyone. There's also the risk of vendor lock-in, which is definitely an aim of the big providers like Apple, Google and Microsoft; which is a bigger risk to those less tech savvy.

FWIW no consumer implementation of passkeys is device bound for exactly this reason. The threat of a user losing a device is much bigger and pressing than getting phished. All passkeys are backed up in a sync fabric.

Most consumer passkey implementations are lock-in. https://arstechnica.com/security/2024/12/passkey-technology-...

And one of the developers of passkeys threatened to use the specified attestation anti-feature to blackball Keepassxc's implementation when they made something not locked in enough.

https://github.com/keepassxreboot/keepassxc/issues/10407

There have been some discussions to create an export standard since then but I remain skeptical. Why was this not part of the original spec but the ban hammer was? Depending upon how this standard is implemented I can easily see it preventing export to anything but Google, Microsoft and Apple's implementations. And it still leaves the attestation badness in place.

I was referring to device bound discoverable credentials and saying all implementations that an average Joe will run across have a sync fabric deliberately. Platform lock-in is a different thing.

AFAIU the attestation referred to here won’t be signed so any implementation can say anything. It’s just supposed to be ise for things like showing the user a logo so they know where their passkey is stored.

Platform/vendor lock-in != device bound

You _can_ use a standalone YubiKey or similar dedicated hardware tokens as a passkey, but they have limited slots for discoverable credentials.

But yeah, anything resembling a phone passkey seems to have a sync fabric behind it.

Something I don't see talked about often regarding passkeys, is that they seem to be useful in addition to other methods, not instead.

I've been thinking that they allow you to have long, non-memorisable unique passwords for an account (1), and then add passkeys on the devices you use often. The long, non-memorisable password isn't inconvenient because you don't need to use it, and the passkeys which are used day to day are resistant to phishing & keyloggers (as I understand).

However, I don't know if that is how they're being used or marketed.

1) Perhaps even 2FA too, which wouldn't be as inconvenient if it's only used rarely. Given the points raised in this article, I'm rethinking whether that is necessary.

Reply on news.ycombinator.com