As someone who is comfortable with TOTP but hasn't tried FIDO-/Yubikey-style devices, I have a few questions:
- 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?
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.
> 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.
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)
> 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.
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
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.
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.
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.
> 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).
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.
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.
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.
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.
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).
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.
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.
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.
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.
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.
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.
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.
> 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.
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.
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.
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.
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.
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.
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.
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.
Just wanted to add since I didn't see this covered in other comments yet --
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.
> 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".
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 ]
I look at it like nothing < SMS 2fac, app OTP, fido2.
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.
I wrote pass-otp because I want to use a hardware token everywhere, not a TOTP secret that can be duplicated. The number 1 complaint I get is that I'm defeating the purpose of 2FA.
Can't speak for this thing specifically, but FIDO2 keys in general:
- 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?)
>- The ideal backup for this is to have a separate key, both authorized.
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.
This is one thing I hate about these keys though - some services only support one key, and for ones that support multiple, I struggle to figure out a storage system for my backup key. I don't want to keep it with me (because then I am at risk of losing both), but if I keep it separate, I need to remember to add it to new accounts - there's no way to see a list of accounts a key has been associated with.
Completely agreed. I don't have a good solution for that either, aside from "try harder". Which puts them in a fairly specific niche of reasonable use, tbh. And any site without the ability to set up multiple emails / keys / etc is not taking basic steps to allow its users to maintain access their account, so I think it's fair to rule them out simply as "bad sites" (though they're quite numerous, sadly).
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.
I keep one of my keys in a fireproof safe at home, and the other on my keychain as my daily driver. If a site allows me to enroll multiple U2F keys, I just bring the backup to work (my home office, currently) with me the next day and enroll it then. For sites that only allow a single key (looking at you, AWS), I will usually enroll the key I have on me, and then when I have both, I write the same TOTP seed to both keys (usually by scanning the QR code with each key plugged into my phone before entering the one-time code used to verify and finalize TOTP enrollment) and use that instead so that there's effectively a TOTP duplicate.
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.
My threat model is focused on remote attacks, I consider physical access to my workstation game over. So one stays on my keys, one on my wife’s keys, and one stays plugged into my workstation.
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.
This isn't really an adequate threat model today though, where everyone has laptops. Having a workstation stolen for most us is actually extremely likely - probably more likely then someone trying to attack our credentials.
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.
This is the biggest weakness of U2F unfortunately.
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.
I keep one backup key in a fire safe at my residence (in case I lose my primary key somehow) and one with a trusted party in a different state (in case Mt. Rainier explodes and the entire state of Washington is lost - though at that point I have bigger concerns)
In non-pandemic times, I visit at least once a year and update things then.
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.
Having multiple keys without auditing when the backups are used, though, feels wrong. And that is my main gripe with these right now. Very hard to get any system to help build the habit of using the things. Most places default to remember your login. Basically forever.
While not cryptographic level auditing, this is arguably a UX feature for sites to implement -- on their inevitable loading spinner after login, they could show you the U2F tokens enrolled, and their most recent use on a small timeline. If your cold backup suddenly goes from ancient to now, that ought to be looked into!
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!
Backups with lower grade technical security are possible if you’re willing to compromise speed. For example an offline process where you have to present yourself, in person, and show N forms of ID, to the service provider or their agent with a mandatory M day delay. Or where you can have X other users, who can log in, vouch for you to reset your access token.
1. I'm not aware of any drivers being needed on any common platform. Support in Android apps is sometimes not perfect, but that's an app issue rather than a driver issue.
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.
Regarding support on Android, if you are using a custom rom like LineageOS without Google Play Services then it won't work currently. Unfortunately, Google implemented FIDO2 in the play services, not in AOSP: https://bugs.chromium.org/p/chromium/issues/detail?id=997538
Interesting and disappointingly. In this case I was testing it with play services, using the nextcloud app. I believe they are using something slightly custom from an open SDK, and suspect the outdoor was at their end.
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.
As others have said, the key not being easy to clone is a feature.
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.
A comment towards Windows10. You actually only would need HID support, but Windows takes over control over fido2 to hide it behind the Windows Hello webauthn API for non elevated users. This makes crossplatform implementations terrible. I own a solo somu and it has much less value due to this on Windows. It really discouraged me to put any more work into fido2 implementations. I started a keepassxc integration, which actually worked well based on the HMAC extension. If anyone from Microsoft reads this: please allow hackers to set a security policy to allow non elevated fido access! Otherwise the devices are great!
I use a yubikey, but I suppose the Solo will be similar.
> - 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?
> 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.
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)
The moment you lose your key, WebAuthN becomes terrible and the UX is atrocious. You may literally have to go to an office (in the middle of a pandemic!) to restore access to your account.
This is bananas. We absolutely should not be recommending them to normal people until security researchers come to their senses and fix this problem.
Nonono. We absolutely should recommend having at least 2. See also: car keys, house keys, any other physical lock you can get comes with at least 2 keys.
The default product sold should be a two key bundle.
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
Trezor is great as an U2F device because it uses the same crypto seed to initialize all internal keys, including the U2F feature. So you only have to backup the seed phrase offline (paper is one of the safest medium when correctly secured, or you can buy a cryptosteel plates to really long-term storage).
Crypto fan or not, those devices are amazingly secure, and certainly hold billions out there. I think it is open source too.
Thank you all so much for the answers! Sorry for my ignorance (or laziness, since I haven't read up on this and don't know of a disinterested guide for techies) about backups; not allowing it is a completely understandable trade-off between security and convenience.
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?
I guess. However, I'd add that it's also definitely a sensible thing to require of people, however non-technical, where you've got some out-of-band way to issue and re-issue these authenticators to those people.
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.
No drivers were needed for my Ubuntu setup or phone, but to have desktop Yubi authenticator app and turn on Linux hardware auth for sudo, login, TTY, I did add a ppa. There instructions for that were good though.
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.
My now-defunct u2f-hidraw-policy package did this in a generic manner. The code was subsequently ported into the upstream udev code, so any up to date distro should automatically detect and handle U2F devices. If they don’t, file an issue with upstream systemd and it’ll get fixed. Feel free to file an issue on u2f-hidraw-policy too if you want my attention.
- 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?