[tialaramex]

Note that you will want to own at least two and enroll both of them to properly lock down a service so that it doesn't need some plan B. The reason is that obviously if it's locked down to a single U2F Security Key and that key breaks or is lost you're screwed.

Google's programme aimed at high risk people (e.g. journalists covering government corruption) specifically aims to leave you in a position where so long as you have control over the physical devices your secrets are safe, and if the devices are destroyed then your account is irrevocably lost and too bad. Doing that with just one key is asking for trouble.

If you're just dipping your toe in the water, buying one key and having your plan B be a bunch of one time codes written in the back of a diary in your locked desk drawer makes sense, and if you're mostly just interested in the cool technology and not worried about security then going to a Key with Google Authenticator as plan B is fine too.

But if you want this to solve all your problems as advertised, buy two keys.

[dmix]

Thanks that’s good advice. Is the idea your token is synced across both devices? Or you have two separate tokens that allow you to authenticate? I’ve only set up a mobile based authenticator per account before...

[tialaramex]

Ordinary Security Keys can't be synchronised so to as to be interchangeable. A good U2F/ WebAuthn implementation lets you enroll several of them and use any each time you sign in. So yeah, separate tokens, any of them works.

It's pretty different from authenticator apps, it can be much more convenient (no trying to quickly type in six digit numbers) but it's kinda expensive for now.

Ordinary Security Keys only know how to do exactly one thing, prove that they're still the same Security Key that they were the last time. They can't even prove which one they are in particular (most can prove which model they are, because a bank or something might be like "Ooh, we like this technology but we insist you use Bank of America brand Keys..." but they don't even know like a "serial number" or anything). This is deliberate - it allows the strongest possible privacy guarantees while still delivering a useful security function. The Firefox implementation lets you pick "No" when sites ask which model it is - I always do, none of their bloody business, it's a Security Key, eat it.

When you "enroll" a Key the site gets back a "cookie" (not an HTTP cookie) that is only useful to identify that site to that Security Key; a Elliptic Curve public key; and a signature proving the Key knows the corresponding private key and was enrolling with this specific web site. The site puts those somewhere (presumably a database table) ready to use them when you log in subsequently.

When you need to log in, the site gets its list of all the keys you've enrolled and says "OK, here are the cookies for some keys you enrolled, prove you still have one". If you have one of these keys it can find its cookie among the set, and it knows the private key that goes with that cookie, so it can sign a new message saying "Hi, this is still me, signing in to $domain right $now" and the site verifies that with the public key.

In principle the Security Key could be keeping a big database of every site it has enrolled with and the cookies used versus private keys. In practice what it does is make a random new private key each time it enrolls, encrypt the private key and put the result in the cookie. Only it knows how to decrypt the cookie, so there's no danger from this approach.

[dmix]

Thanks, I'm going to buy more than one for backup and use the multi-key approach. Appreciate the long explanation. I've been meaning to set this up for years.

This should be standard practice taught to kids in school! Especially considering their whole life is digital now.

I saw that Linux's full disk encryption supports Yubikey as well as Gnome login screens which is neat.