[kelnos]

Others have answered most of your questions, but there's something I think deserves emphasizing:

In general, you cannot (by design) back up these devices; if you could, that would defeat a lot of the security they provide. That means that if you lose it, you will have to find a way to get 2FA disabled for each and every account you enabled it for. Some orgs will have pretty onerous (but necessary!) processes for doing so, like having to provide government ID or physically visiting a brick-and-mortar location to prove your identity and ownership of the account.

Some sites will allow you to simultaneously enroll two devices, so you can keep one as a backup, safe somewhere (though not too safe; if you were to, say, put it in a bank safe deposit box, it'd be a pain to fetch it any time you want to add a new account). But many sites only allow a single device to be enrolled.

Some (like Yubico) let you purchase a "cloned" set of devices, where you can get two (or more) devices with the same keys on them, so you could actually put one of them in a safe deposit box as soon as it comes in the mail to act as a backup. That also solves the issue of some sites only supporting one device, as all of the devices in the set are effectively the same device. However, it doesn't appear that this is an option with the Solo keys (not certain of this; happy to be wrong about it; it's possible that you might be able to wipe the key material off new Solo keys and put identical copies of new self-generated material onto more than one key). On the flip side, if someone steals your backup key, it becomes harder to deal with the situation; with distinct keys, you can just revoke access to the stolen key. But with cloned keys, revoking access to the stolen key will also revoke the key you use daily.

I just wanted to bring this aspect up, because people unfamiliar with these devices need to understand the consequences if they lose their key; it can be a huge pain in the ass to rectify that situation. This might be an understandably big turn-off to non-techies who are just looking to add a little extra security, but not a big maintenance burden and difficult failure modes.

[tialaramex]

> Some sites will allow you to simultaneously enroll two devices, so you can keep one as a backup

For WebAuthn (the actual standard for how to do this which is what you should be rolling out if you have a greenfield authentication environment that doesn't already do U2F today) the specification explicitly says:

> Relying Parties SHOULD allow and encourage users to register multiple credentials to the same account. Relying Parties SHOULD make use of the excludeCredentials and user.id options to ensure that these different credentials are bound to different authenticators.

https://w3c.github.io/webauthn/#sctn-credential-loss-key-mob...

I'm aware of (and along with many of its other users annoyed that) AWS only permits a single authenticator. If there are other popular sites that do this, this is no worse a place than any other to say so.

FWIW I have two (or more) FIDO authenticators with Google, GitHub, GitLab, Facebook, Dropbox, Login.gov and Digidentity (the Gov.UK verify provider)

[Corrado]

> I'm aware of (and along with many of its other users annoyed that) AWS only permits a single authenticator. If there are other popular sites that do this, this is no worse a place than any other to say so.

Just to clarify, AWS only allows a single authenticator for their IAM users. If you are using AWS SSO then you can have multiple authenticators. And yes, I am very annoyed and frustrating to think that IAM is forced into a lower security profile that it needs to be.

[godelski]

This has been a thing preventing me from getting one. A key that's supposed to be on you (or locked in a vault) is prone to getting destroyed or damaged.

So since my threat model isn't high and this would be more a nerd thing, it doesn't seem worth it. 2FA is good enough I guess

[lucideer]

Fwiw, I have 3 of these and I have yet to encounter a service that doesn't support all three, so it hasn't been a issue.

People have mentioned AWS IAMS only supports one at a time, but that's definitely "a nerd thing".

The only "normal" user-facing service I've tried with some unnecessary restrictions is actually Twitch (also an Amazon property), so it sounds like Amazon are just specifically bad at this, rather than most companies having bad implementations.

But in general, it's been fine for the vast majority of services.

[chrisdhal]

I've had a Yubikey for about 3 years that is on my car keys keychain which goes with me everywhere. It's been all over the US and into Costa Rica all in my pocket or haphazardly thrown into my backpack (with a bunch of other random things).

There is zero evidence of any wear or anything. They are meant to be carried around, you don't need to baby them. I'm more worried about it being lost than damaged.

[ozim]

My friend was like "why would I pay for this when Android phone can act as one as well".

I am more concerned with losing my phone or that my phone will die that something happening to my ybk.

[kelnos]

That's good to hear! I was under the impression that it was much more common for sites to not support a second device. Glad to know most do.

[brewdad]

In my experience every site I set up a physical device with offered either multiple device support or a secondary method like TOTP as a backup. Not as secure, but much more user friendly, recognizing that we are all only human.

[smichel17]

> But many sites only allow a single device to be enrolled.

Ugh, I hate these. I want to use u2f, but I am not willing to risk being locked out of my account if I lose the key. So I only enable it if there is some other 2fa I can enable (either adding a second key or totp).

[tialaramex]

Most sites which offer U2F (or WebAuthn, which is what they ought to be doing for new sites) have a last ditch "Write down this huge random string" way back in. If you're the sort of person who'd hate to lose an account (seems like you are) then you should definitely write that down, and keep it somewhere damn safe.

But, as I wrote elsewhere in this thread, the only site I'm aware of that forbids multiple Authenticators (Security Keys) is AWS. And to be fair, AWS accounts are multi-user. If Bob loses his Security Key and Bob was your only admin, the biggest mistake wasn't AWS forbidding Bob from having two keys (though I agree that's bad) it's you not assigning another admin. Jim, the company secretary, may not know a t2.nano from m4.xlarge but he can keep a Security Key in his desk drawer and never give it to anybody unless the Big Boss authorises it.

[Xylakant]

There’s one special account though and that’s the AWS root account. It’s needed for certain special things and tying it to a yubikey means that you cannot easily give those a creds to 2 people.

[fullstop]

Google won't let you enable "enhanced security" unless you have more than one u2f key.

[stouset]

> Some (like Yubico) let you purchase a "cloned" set of devices

Wait, they do? How?

I would love to do this, but I can't find anything relevant on their website.

[kelnos]

After going through their "what do I need?" quiz, it seemed to indicate that was an option. It's possible that I misunderstood, and they just give you two independent keys.

[tialaramex]

I think that quiz would like you to buy two of their products, which is a thing you might want to do (I'd suggest maybe one of theirs and one from a rival, but they're not going to suggest that) but it is not implying those keys are identical inside, they are as you say "independent keys".

So you'd register both keys. Or if you own more, you'd register at least two of them and at least one stays somewhere safe (but like, not in a bank safety deposit box, maybe the sort of place you keep a passport). This way, when inevitably your toddler throws mummy's key ring into a fast moving river, it's just very inconvenient and doesn't ruin your whole year. After you call somebody to bring a spare car key, and ask the toddler to think about what they did, go revoke all those now useless keys and order a new FIDO authenticator.

Edited to add: Even if they started identical you can reset any Yubikey, making the keys inside it random - and very paranoid people might want to before using it, since you don't know what happened to the keys inside it before you got it.

[dandanua]

The existence of a cloned physical key is not possible due to FIDO U2F protocol. Every sign operation increases a counter on the device. It's supposed that services will keep track of this counter and don't accept signatures with an incorrect counter (less than known).

[_trampeltier]

The same for me. I bought 2 keys and the idea was to have one as a backup key. But I did not find a way to do it. Anyway, even after read about how it works on some websites and watched some videos, the whole things is still a bit of a black box for me. I have no idea how a non-techie at moment a such device can use safe.

[sammorrowdrums]

I just bought two keys and most services let me enroll two devices or can use Yubico Authenticator, so I scan the OTP barcode twice, and tap each key one time on phone.

Then I'm going to sit with my wife and do that for some of her accounts and she will hold my backup.

edit for clarification, you really do need to have two devices with you to safely enough register 2fa, but obiously it is not safe to keep them both with you after initial setup, in case you lose them both. For the most part you just switch it on for everything with dual keys somehow (even if one registered key plus one Yubi Authenticator OTP).

For services that only actually enable one key, if they have emergency backup codes keep them in password manager, physical safe or a somewhere in your home depending on your threat level and the risks of the particular service being compromised.

[mkj]

I assume the solokey generates its master key on-device. Seems like it wouldn't be too hard for it to perform Diffie Hellman key exchange with another device to get a shared secret (at first setup) then they could be a cloned pair.

[g_p]

The issue with this would be counter synchronisation, as services shouldn't accept cloned responses when the counter ceases to be monotonic for what should be one single device.

[ahnick]

Some devices derive their keys from a recovery seed that you can store offline in paper form. The benefit of this approach is that you can recreate the key on a backup device using the recovery seed, should you lose your primary.

[kelnos]

Ah, neat, so basically the recovery seed would let you buy a new device and then use it to "clone" your old one?

Definitely useful in case you lose it or it gets stolen, but you'd end up wanting to rotate to a new key with fresh seeds anyway, since the old key could be in the hands of an attacker. I guess this is still useful in the case where you don't lose the old key, but instead damage or destroy it by accident.

[ahnick]

Yes, exactly. If you lose it or it's stolen, then you'd want to rotate to a new key quickly. Some of these devices have a pin too, so the attacker needs to crack the pin before they can actually use the device. This should hopefully buy you enough time to bring up a new device and switch over accounts. That's why it's probably a good idea to buy your second device when you buy your first one and store it in a separate, reasonably secure, but more importantly, quickly accessible, location.

[vlovich123]

> On the flip side, if someone steals your backup key, it becomes harder to deal with the situation; with distinct keys, you can just revoke access to the stolen key. But with cloned keys, revoking access to the stolen key will also revoke the key you use daily.

Get a new key, revoke old key, switch to new one?

[kelnos]

Right, but the "get new key" bit means that your accounts are in a vulnerable state while you're getting the new key.

If you have two independent keys, and you learn that your backup key is compromised, you immediately revoke it with all services, and order a new one. When the new one arrives, it becomes your new backup, and you enroll that in everything. Your vulnerability to an attacker ends immediately after you find that your backup key has been stolen and you revoke it.

If you have two identical keys, and you learn your backup key is compromised, you order a new one (or pair, rather), but you can't revoke the old key until the new one arrives, when and you can (simultaneously) revoke the old and enroll the new.

[FeepingCreature]

Of course, the problem here is that the attacker can also revoke your backup key, and since they're the attacker, they can probably do it faster than you.

Preferably I'd have a certificate chain scheme where I have a private revocation key sitting in a safe somewhere whose public key I specify everywhere, so I don't even need to take it out of the safe to sign up somewhere.

[dheera]

The way this should be solved is for everyone to enable multiple U2F keys in every site and de-register any device or key that is stolen.

Unfortunately many sites suck at this. AWS, Twilio, PayPal all suck.

[andrewwebber]

Looking at you AWS cloud.

[Corrado]

Just to be clear, AWS SSO supports multiple keys. Yes, AWS IAM only supports a single key and it's very frustrating. If you want multiple key support, I suggest moving to AWS SSO. It's much better in every way.

[xenophonf]

That doesn't help if you're trying to protect the AWS root account.

[baby]

Some websites also allow you to disable or rotate your 2FA creds if you're already logged in, without having to re-authenticate with your second authenticator.

[jabbany]

This seems a little dangerous since now the logged in state (likely cookies but maybe also hashed with identifiers like IP etc.) becomes considerably more valuable to steal.

I actually see the opposite done, where any changes to login related things (passwords, 2fa keys) mandate a 2fa re-auth.

[baby]

Heh, stealing a logged state is bad no matter what unless you’re requiring re-auth on important operations. The risk of one losing their second factor is much much higher.

[jabbany]

Yeah, this is a very good point.

I deal with this by always adding a second "cold" key when services allow multiple keys, and keeping this cold key somewhere secure as a backup spare. So if I do, say, lose my primary key, I can at least pull out the spare key to reset and de-associate the primary.