Hacker News Reader

Comment by timwis | Hacker News Reader

As much as I want a hardware key, I still struggle with the practicality of having a backup key. I create new accounts on websites quite often, and the idea of having to go fetch my backup key out of a safe to register it (and hope the site allows multiple keys) just feels impractical (“I’ll do it tomorrow”). Not to mention—what if I’m at work, or out and about setting it up on my phone? Am I really going to remember to add my backup key when I get home every time?

Wish there were a way around this :/

View on HN

My "solution" to this problem is: hardware keys with backups for the really important services—Bitwarden, Google, domain registrar, etc. And then for stuff that isn't absolutely critical, I just use an OTP stored in Bitwarden. As for having both the password and OTP stored in the same place, the way I see it, the OTP is mainly protecting against keyloggers, data breaches, etc. And then I figure, if someone gets into my Bitwarden account, I'm already fucked anyway, so it's whatever.

I currently have four Yubikeys: one on my keychain, one in my apartment, one to take with me while traveling, and one at my parents' house. I figure this should be adequate to ensure I never get locked out of Bitwarden or Google, which would be an utter disaster.

That sounds like a pretty reasonable solution, just doing it for the ‘crown jewels’.

The OTP in the password manager one is another thing I’ve struggled to wrap my head around. There’s an interesting conversation about it with folks at 1Password for those interested: https://1password.community/discussion/101714/why-is-it-a-go...

Now that Bitwarden supports passkeys, I hope the "copy 2fa code to clipboard" approach to 2fa integration will soon come to an end.

What do you imagine a solution here might look like? I don’t know enough about the problem space to truly know, but I feel like I’ve seen versions of this: I can authorize any arbitrary public key for use over SSH, for example; and (based on my memory of YubiOTP) it’s seemed like at least some of these hardware auth protocols work based on using an open serial number or public key to identify the authorized authenticator.

Intuitively it seems like it should be possible for me to store on my main auth device some form of the backup device’s identity or public key material, and at enrollment time, ask the authenticating service to trust either the current device or also this other device to authenticate me.

I wonder what risks I’m overlooking-surely there must be good reasons the protocol excludes that kind of approach.

Perhaps if you could register your hardware key using its public key, which could be saved on your device? So you don’t need the hardware keys to be physically present when registering; just when signing in later.

In FIDO a separate public+private key pair is minted for each (key,site) pairing. This has lots of important benefits, but one is that it preserves existing anonymity.

If I use a Security Key to sign into Facebook as "Melissa Smith" and use the same Security Key to sign into my GitHub account "acab420", even if Facebook and Microsoft work very hard they can't correlate the information they have to prove those are being authenticated with the same authenticator. The keys are different, as they would be if these were different authenticators.

You might think it's impossible for FIDO1 or in scenarios where it's "just" a second factor and isn't storing anything for the site on your key, but there's a really clever trick. The Relying Party (e.g. web site) is required to remember a large random-looking "ID" for your key. Those aren't really random - they're effectively your private key for that site, but encrypted using a symmetric key only your authenticator knows. It encrypted its own private key and just sent that, in plain text, knowing it's impossible to decrypt (typically AES-128 or similar) and when the ID is sent back, the authenticator just decrypts it. AEAD is used, so an authenticator can tell if this ID isn't one it made because the AEAD fails.

Thanks, that's a really helpful explanation.

I wonder if the actual desire is to be able to buy a set of cloned keys. I.e. instead of having each key be unique, be able to buy a set of N keys with identical private key. Or the ability to create such a set yourself with a special initialization sequence. This would give you your high-availability backup, but means you cannot revoke the first key if lost. So it seems like you'd really have to trust the other hardware protections and PIN/lock features if misuse of a lost/stolen key is a concern.

Periodically, I try to think if there is some other expected UX you might want that is somehow neither cloned nor independent keys. Like some hybrid of secret-sharing and group key schemes. Have a set of N keys which know about each other and can act individually to authenticate for the same identities, including for new identities enrolled by any key in the group, as in the case of a cloned key. But, include some capability for k out of N keys to "vote out" a member from the group in order to revoke the lost key and prevent it from authenticating any of the identities in the future.

I am not a cryptologist, but I can't really imagine any crypto mechanism to actually produce this combination of effects. A fully distributed group registration and authentication effect during normal use, so enrollment via one key can be followed by authentication using another. But at the same time, allowing ejection a member from the group to prevent future misuse. I can only imagine this as a protocol, where every authentication for the group would have to consult some centralized ledger or revocation list for the group membership. It could be decentralized/federated in a sense, but would require some kind of online check with the "latest" ledger state for a given key group.

You can use a software passkey and still get 99% of the benefit. For the other 1%, you can't have it both ways, where a hardware key is both required and not required to sign in.

Maybe there can be better UX around signing up, ie "give me your public keys so I can set them up in your account", but then you lose a lot of the privacy, because the public keys aren't different per site any more (and operators can then tell the same person has an account on multiple sites).

> the idea of having to go fetch my backup key out of a safe to register it (and hope the site allows multiple keys) just feels impractical

An alternative some people use is to register a TOTP code and print out the QR code. Then you can remove it from the app. It's not a full solution but it might be part of one that works for you.

> Wish there were a way around this :/

I very much wonder if this obvious oversight was intentionally left unaddressed in order to create a requirement on proprietary sync/backup solutions and make true security more difficult (since the key material is now being synced around and could technically leak or be subject to "lawful intercept" or bruteforce of the sync service's authentication).

Reply on news.ycombinator.com