Hacker News Reader

Comment by jupp0r | Hacker News Reader

Yubikey recommends a backup key for that very reason. Most providers allow you to register multiple keys.

While it's not a bad idea, I'm pretty sure Yubikey recommends a backup key so that they can sell twice as many Yubikeys.

I use the "multiple security keys" approach, and the biggest problem is keeping track of which keys are registered with which services and making sure the list is up to date. A few examples of situations where this is a problem:

1) I don't keep all of my keys on my person, so if I want to sign up for a service when I'm not at home, I have to remember to go back and add my other keys at a later time. If I wanted to, for example, keep a backup key in an offsite location such as a safe deposit box, this would be even more painful.

2) If I lose a key, I need to go and change every service to deactivate the lost key and add my replacement key. This is both time-consuming and error-prone, as it requires me to keep a full list of providers that I use keys with somewhere.

3) Some providers do not even allow you to register multiple keys.

The way it’s meant to be done:

1. You register both the primary and the backup key with every identity provider (ie GitHub)

2. You only carry the primary key with you at all times. You keep the backup key in a physically safe space (ie next to your birth certificate).

3. In case the primary key gets lost, you make the backup key your new primary key. You can log in with it everywhere because you already registered it in step 1.

4. You order a new key which will become your new backup key.

5. Go to step 1.

"providers allow you to register multiple keys"

Why isn't my identity just a Merkle root? I don't understand the need to register individual keys.

You'd also need some way to revoke keys signed by the root if a valid hardware key were lost, stolen, or confiscated.

I think Yubico will actually do something like this for large enough customers, though revocation is left as an exercise for the customer. When I worked for AWS, I was issued a couple company YubiKeys, and there was a web portal where I could revoke a token's association with my account.

How would you add a new key at a later point in time (i.e. after your initial registration of e.g. a main and a backup key, after having lost the main key and wanting to add a new backup/main key)?

The FIDO/WebAuthN model does by design not include a stateful/centralized authority that could maintain the required state for any such solution.

A backup key is a good idea, but there needs to be a way to enroll the backup key for a new account (ideally automatically) without the key being physically present, since otherwise you can't (practically) store the backup key off-site. To this end, you should be able to enroll a key using only the public part of the keypair.

https://www.yubico.com/blog/yubico-proposes-webauthn-protoco... is a solution for that

And where do you store the backup key?

In each one of my PCs and also on my key-ring is how I do it.

If you sign up using one key, do the other keys work with that account? Unless it does, you're greatly increasing the complexity of creating new accounts anywhere.

That's basically what I'm getting at. Do I need to do significant amounts of extra work to keep an off-site backup in another state?

I don't personally consider it greatly increasing complexity. At account creation I register the Yubikeys at the PC and on my keyring. When I first login from a different PC I use the Yubikey from my keyring to login and then register the Yubikey at this new PC.

Sounds like we should be doing FIDO with TPM then.

Sounds miserable compared to using a password manager.

Next to your birth certificate

Yep! Just store your backup key in a safe-deposit box with your bank.

Then go get it every time you sign up for a new account so you can make it the backup for that account

then go store it again.

and again. and again. and again.

oh no! you lost your key! time to go to the bank to get your backup, sign in to all the accounts, remove the old key, register a new backup, oh wait, got to wait for the new backup to ship, so i guess you can't do that yet. hope you don't lose your key in the meantime, anywho, time to spend a few hours painstakingly removing your lost key from all the 9 thousand sites you use.

yay! its a week to a month later, you finally got your new yubikey shipped, time to go log into to 9 thousand websites again to set it up as the backup for all of the sites.

Ok, time to take it down to the bank.

whats this? a cool new app my friend wants to show me, ok, time to go drive to the bank and get my backup key out of storage and sign up for this cool new app.

You know, this whole driving to the bank thing, its kinda inconvenient, maybe i should just store it in my closet safe.

What do you mean the gas line under my house exploded? but both my yubikeys are in there!

----

The above is fiction, and even under fiction it seems ridiculous how this would really go is even worse:

"Go get my backup key to use for this new app my friend showed me? fuck that"

. .

"What do you mean i can't reset my password, but i lost my yubikey!"

"No, i didn't want to get up to grab my backup token when i was registering."

"Oh wait! i bet i still have the recovery codes as a pdf in my downloads folder. its a good thing no viruses ever think to look in there"

----

There is no need for your described complexity.

More advanced FIDO devices like the Ledger allow you to backup the initial random seed allowing you to create a duplicate device from the backup any time you wish. No sites you signed up with will know or care that you swapped devices as the new device will generate identical keys via a deterministic KDF from the seed.

You can put this seed far away and would only ever need it when you wish to replace a lost or broken authentication device.

Aside: no US major banks issue safety deposit boxes anymore other than wells fargo which will stop issuing them soon as well.

Reply on news.ycombinator.com