Hacker News Reader

Comment by johncolanduoni | Hacker News Reader

How many people are doing a spring cleaning of unused passkeys in their password managers? We're talking like a kilobyte of data, nobody needs to delete these things in any kind of normal circumstance.

Sure, it would be great if users would store 5 copies of their encryption keys, with one in a lockbox on the bottom of the ocean. But that's just not going to happen at any kind of scale, so an automatic way of putting encryption keys in a replicated password manager makes sense. And compared to how people normally handle end-to-end encryption keys, it's going to result in a lot less loss data in practice.

View on HN

I don't know about spring cleaning, but it's pretty easy to delete by accident if you connect to the browser or OS when setting up instead of the password manager.

That said, I've been assuming I could have multiple passkeys per site and that's turning out to not always be something websites behave sanely about.

Most password managers implementing passkeys only allow one passkey per account entry, and I've ended up with multiple passkeys per site, while the site only supports one (and deletes the others upon creating a new one), so I've been in the exact situation of not knowing which entries are safe to delete before.

This is usually due to relying party and possibly password manager bugs, but it does happen.

I thought the point of passkey security is that you don't have to send the private key around, it can stay on your device. Different passkey per device. Lose or destroy a device, delete that passkey and move on.

That’s how I use them. Passkeys on two Yubikeys. And I tag in my password manager which credentials have what form of auth. UP, TOTP (also stored on the two Yubikeys), Webauthn or passkeys (the former indicating 2FA).

None of the password managers (including but not limited to ones built-in iOS/Android) work that way. The Apple one (and I think Google is the same) keeps the private key inside the secure enclave (security processor), but it is still copied to each new device - though it is end-to-end encrypted during that transmission.

The issue there being there's a big usability headache with enrolling multiple devices. You really want one device to be able to enroll all your devices (including not-present and offline), but there's no mechanism to do this with the way the webauthn spec works at the moment.

That's such a bummer and seems like poor design. It ought to be easy for a user to have multiple keys associated with their account.

Reply on news.ycombinator.com