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.
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)
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.
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
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.
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.
I am more concerned with losing my phone or that my phone will die that something happening to my ybk.
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).
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.
Wait, they do? How?
I would love to do this, but I can't find anything relevant on their website.
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.
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.
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.
Get a new key, revoke old key, switch to new one?
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.
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.
Unfortunately many sites suck at this. AWS, Twilio, PayPal all suck.
I actually see the opposite done, where any changes to login related things (passwords, 2fa keys) mandate a 2fa re-auth.
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.
TOTP and any sort of one time code authentication are just as phishable as passwords. Perhaps the biggest benefit for most people using U2F or FIDO2, is the large resistance to phishing.
This is because of how the whole ecosystem has adopted FIDO2. When a FIDO2 key signs an assertion for a website, it includes the domain in the signature base, e.g. "example.com". The browser enforces that the request to the FIDO2 key always uses the correct name of the domain you're on.
If you accidentally go to a fake website, "exaample.com", then the key will make a signature for "exaample.com", which is invalid for "example.com". Nothing can be phished to get around that, unlike OTP codes.
Even if you have other 2FA options linked to your account, as long as you're using your FIDO2 key, you gain this benefit. Very strong benefit for both individuals and enterprises.
This actually isn't true - the result is even better.
When you visit fake.example instead of real.example there are two scenarios: For FIDO2 (like this product) with usernameless mode, just as with a modern iPhone or fancy Android with fingerprint reader, the authenticator knows perfectly well that you've never registered at fake.example so, you can't very well authenticate to it, you get an error.
With FIDO1 (or on sites that don't use the usernameless feature anyway) the authenticator has no idea you've never visited fake.example... but the site has to hand over an opaque ID, a large binary blob. This is (either directly or in effect) actually your private key, encrypted in AEAD mode using a symmetric key known only to your authenticator. Another ingredient to this encryption is the domain name. So either fake.example hands over a random blob, which is gibberish, or they hand over a genuine real.example blob... but they're fake.example so the decryption fails. You get an error.
The way I found this out was by trying it, I built a toy site with WebAuthn authentication. If I run the same code, on another site I own, it gets an error in the Javascript telling it that apparently I don't yet have a Security Key enrolled for this site, maybe it should enroll me first. If I tell it to pretend it's a different site, it gets an error saying no it isn't.
[ The bad guys could enroll you, but now you're really signing into their web site. Which is cool, but, doesn't actually help them phish credentials for the other site ]
Every layer buys you a little bit (or a lot) more, raising the skill level and/or cost. Fido2 is much harder to phish but of course weaknesses may be found in the future.
- Yes, you have everything you need on every major OS/browser
- These devices are zeroconf; resetting it actually kills a security feature (key use increments) aiming at cloned devices
- The ideal backup for this is to have a separate key, both authorized. They don't need to have the same material, in fact, cloning it would be considered a weakness (how do you know someone hasn't cloned it without your knowledge?)
This in particular is important. Security is only as strong as your weakest link, so any backup methods (e.g. "forgot password" flows) might as well be your primary method, if you actually care to strongly secure things.
Adding another (or more) key gets you same-security redundancy if one fails or is lost. Nothing else will achieve this.
Degrading to "forgot password" may be entirely fine for [person's] use of a security key, but you must be explicit about that decision, or it's mostly security snake-oil.
I'm curious how others handle this.
For corporate purposes, they're pretty decent. If one is lost or fails or whatever, they can get you a new one, because the company can quite-strongly verify that you are you - much better than your average website. A bank or something might also be reasonable.
For general personal use... I dunno. You really don't want to be locked out permanently if you lose the key, which tends to mean they degrade to your email security, and they're just convenience tools. Which is more than nothing! Convenience that emails you when it is bypassed is better than no email when bypassed! But it's very far from the security claims that tend to go along with these keys.
Personally I'd like these keys to be a "fast login" convenience, and for email-reset to be delayed by a day or three with an easy "revoke" button. It's exceedingly rare that I truly need backup access immediately, and allowing it all the time is definitely opening the door to bulk theft of accounts.
This gives me a pretty convenient list of sites I've set up the Yubikey with (at least for TOTP), since Yubico's OTP app lists all the sites I've used it for.
If a site only allows a single U2F key to be registered, I'd rather have a backup with TOTP over the better security of a single U2F key, so this arrangement works reasonably well for me.
If I’m enrolling the keys with a given service I make sure to add or remove all three at the same time so I don’t have to track which is associated with different accounts.
In this case though, full-disk encryption and TPM usage is the mitigation - provided the disk goes dead when anyone short of a nation-state tries to manipulate it, you're good.
My approach is to keep a list (a simple text file) of what services are used for U2F, and which keys are enrolled with it.
Most services ask or require you to name the token you enrol (if they support multiple tokens) - I gave the tokens names so they're consistent.
Now I have 2 ways to check - logging into a site, you can see what keys are enrolled. And as fallback, I can use my underlying text file and see which keys I enrolled.
You just need to make a point to check the file once every so often (at least first time you are near your backup key after having edited the text file).
I've seen some interesting approaches (on modifiable tokens where keys can be exported) where they configure a backup key as a mirror of the main key, but with the counter advanced forward such that using the backup will invalidate the regular (thus alerting you to the use of the backup by an adversary, as long as the service properly validates the counter).
I can't think of an easy solution to this (it is effectively the key distribution problem) without adding complexity (like manager software for tokens, and a Shamir's secret sharing style way to export a token's root key through SSS such that it can be recovered by a quorum of keys in an emergency). That breaks various aspects of the threat model though.
Perhaps there's a less complex way to do it though? Like having up to N persistent public key slots on the token, where public keys of your other tokens can reside. When registering, the generated key is also encrypted "to" those tokens, and sent as supplementary key handles. You'd need to add a pairing relationship to validate authenticity of the key handles, but I suppose it could work.
At the end of the day, so long as I can get access to my email and at least one bank, I'm confident that I can recover everything else in time. As such, if I have some recent account that isn't covered by that key I'm not particularly concerned.
Regards habits, I find U2F is so easy to use that there's no real issue there. The bigger issue is that (relatively) few services support it. I'd much prefer to use it over TOTP phone generated codes, but far more sites seem to support phone app generated codes (while pretending you need their proprietary app to use them, even when it's just plain TOTP) or, even worse, SMS!
My problem with the habit remains, though. I would love if my phone insisted me try a key at least once a week. I don't know how to force that. :(
2. No software is required - far easier to use than you describe. You insert it, tap the button when prompted, and that's it. The token will decrypt an wrapped key (held by the remote service) using a hardware backed key, and sign an attestation using it. This attestation is tied to the domain name and URL scheme being accessed, so it "prevents" phishing as you can't trick users into relaying useful tokens.
Note for FIDO2 there may be software to help manage more complex setups like "no username and password needed to login". If you're talking U2F (i.e. just 2FA), no software required.
3. You don't. There isn't anything to back up. You cannot export the internal key state, but services you use hold the (wrapped, encrypted and authenticated) key used for their service server-side. Your device just decrypts it, uses it, and discards it. You do need to think about backup, but you do that by enrolling 2 or more U2F/FIDO2 keys on each service you protect. That's the downside - you need to remember to enrol both keys on each service, every time you make a new account you protect with U2F.
4. Not really, beyond support at service side being limited (mostly) to big security-aware services.
It seems strange Google put fido2 into play services, but that's certainly what they seem to "need" to do to get things shipped, given the lack of prompt Android release updates (don't even start me on longevity...)
Still unfortunate every time this happens, as AOSP just loses more and more functionality.
While I understand why this is and which threat models this addresses, I still think that this shouldn't be an all or nothing proposition.
In the general case, meaning not for people with access to "secure systems" (corporate) or who are high-profile enough to have reason to believe that they themselves may be a target, I think that having "less secure" keys which can be cloned by "non-techies" might still be an improvement to the overall security of the internet.
I didn't do any research, but according to the linked Kickstarter page:
Solo V2 greatly reduces the risk of security breaches, as over 80% of all breaches are caused by passwords compromised through phishing email attacks.
So physically stealing credentials isn't as widespread a risk as phishing, which doesn't really surprise me. Therefore I think Webauthn with "cloneable" keys would be a net positive for "regular people".
This wouldn't preclude "techies" from using more secure, unclonable keys like the Yubikey & friends. But my grandma could also use a "less secure" one without the risk of having to go through resetting 100 different sites and would be able to setup a new key just by having me walk her through the process of restoring a key from a backup. I'm a "techie" and even I would like such a key for use on random "must absolutely register" websites.
Of course there's the issue that if the key is lost you can't easily revoke it. But even with the proposed system of having a backup key registered or going through the recover account process, as long as you don't actively go unregister the lost key it's still registered and working. So if the authentication is based on some sort of counter, the process of effectively disabling the lost token shouldn't be any harder in this configuration.
> - Are drivers for this already installed as part of desktop Ubuntu 20.10/Windows 10? Any driver installation will absolutely make this a no-go for family members.
On windows10, yes. I haven't tried it on Ubuntu 20.10 yet, but I think FIDO/WebAuthN will Just Work. (PIV will likely need custom software, but if you're using PIV, you probably know what you're doing).
> - Is additional software required for anything non-techies might reasonably want to do with this device, including resetting it
I mean, you rarely want to reset your key to start with, but at least for the yubikey, this requires external software last I checked. Maybe there's a button hidden in the chrome browser UI, but I've never found it. You need yubikey manager (which is yubikey's tool for doing various operations on the yubikey, like configuring what the touch button does, etc...).
> adding an entry
This is done entirely through your browser when setting up 2FA for a website that supports FIDO/WebAuthN. This is done entirely transparently for the user.
> or checking which entries are already on the device?
I don't think you even can do this. I'm not entirely sure how FIDO works, but I think the key is basically derived from some kind of "master" key combined with the domain you're connecting to. So the key doesn't actually have any memory of which servers it ever connected to.
> - Is there anything else which would likely stop non-techies from using this for basically everything they care about?
Well, technically, I don't think there's anything. WebAuthN is rock solid and the UX is really as good as it gets, IMO. The problem is, for many people 2FA is a hassle they don't want to go through. They don't see the need for it. And TBF, for many people, they might be right: they might not need it. So why go through the hassle?
Indeed, this is one of the most elegant features of U2F - it preserves security and privacy even in relatively adversarial edge cases.
Your token has a hardware-backed long term key in it (well, one for encryption and one for authentication). When you enrol on a website, the token generates a new asymmetric keypair internally, then encrypts and authenticates it with the long lived keys. The registration bundle sent to the server is called a "key handle", but is typically just the a hardware wrapped key.
When you visit a site and log in, on the 2fa prompt, the site sends the encrypted wrapped key back to the browser, and it tries verifies it's a valid key, then decrypts it, and does a challenge-response authentication that's tied to the HTTP origin (domain and port) of the request.
What's quite nice is that (outside of a few corner cases like looking at counter values and trying to correlate), you can safely use one u2f key with multiple accounts on multiple services, and none can be linked by the u2f key. (Of course they can be linked through other means, but the token won't be that link)
This is bananas. We absolutely should not be recommending them to normal people until security researchers come to their senses and fix this problem.
The default product sold should be a two key bundle.
U2F desperately needs a layer of indirection that doesn't currently exist.
It should work out of the box on windows 10 and ubuntu. Microsoft is actually one of the largest forces behind the FIDO2 spec. Windows Hello implements FIDO2 too so you can use it dven without a dongle but just with your biometric reader on our laptop
Crypto fan or not, those devices are amazingly secure, and certainly hold billions out there. I think it is open source too.
It sounds like this is a perfect solution for people at high risk of phishing, a good solution for somewhat technical laypeople with something important to protect which supports this (like a bank account), and too much hassle/risk of losing access/lack of support for most people/use cases. Does that sound fair?
Suppose you're Twitter. If every Twitter employee has a FIDO2 device and they need to tap it to begin their work day, and to confirm any important actions like "Block YetAnotherNazi" or "Validate that this Twitter account really does represent Jim's 24 hour Celery and Dog Collar Deliveries" then instantly a bunch of your security problems disappear, and all you need are your existing procedures that stop random people walking into your offices off the street and pretending to be employees, which, I'm going to guess, is already a problem you've got at Twitter.
I can't see any reason a university wouldn't do this for its students for example. Or a hospital for its medical staff. Or a police force for... all the cops. These are very easy to use, with that one sharp edge of "What if I lose it?" which is not a problem if your organisation already has procedures to ensure only the right people get physical ID.
And when setting up any 2fa, need to have two keys and enroll them both, to give a chance of account recovery.
edit I purchased one for my wife and only properly understood when it arrived that it would need to be first used for all my 2fa, and then when helping her get setup I would need to have mine handy as her backup too.
To make a backup, you get 2 different keys and set them both up. The second one you keep somewhere safe, for example in a safety deposit box at a bank.
A bit more convenient than having to use the YubiKey apps for TOTP and such.
- Are drivers for this already installed as part of desktop Ubuntu 20.10/Windows 10? Any driver installation will absolutely make this a no-go for family members.
- Is additional software required for anything non-techies might reasonably want to do with this device, including resetting it, adding an entry or checking which entries are already on the device? The ideal would probably be if the device acts like a USB stick, with entries being shown as .bin/.txt files which can be manipulated in the normal ways.
- How easy is it to create a backup? The ideal (for non-techies) would probably be something like plugging a device into a PC and simply copying files across. Ditto for duplicating to another device.
- Is there anything else which would likely stop non-techies from using this for basically everything they care about?