[palisade]

Hm, I suppose, though that is the functionality the poster I was replying to was discussing. Though, one has to wonder, what other flaws are lurking below the surface on that chip. It isn't flawless. Once there is another major issue it is going to be an abandon ship type of situation. What are the alternatives if any, move to a new key that doesn't have the problem or look into an alternative means, etc.

[munchbunny]

I think this is a revocation and provisioning problem: when the device is compromised, how hard is it to revoke that device and provision a new one for yourself?

Structurally, actually making these tokens should be commoditized anyway. So on the software side, it needs to be not absolutely painful to rotate credentials. Something like a one-time-pad that you can use in "in case of fire break glass" situations.

[tialaramex]

If you've ever used GitHub's SSH keys provisioning, any halfway decent U2F or WebAuthn implementation (including GitHub's) works a lot like that.

You can register as many keys as you like within reason, you can give them names like "Yubico" or "Keyfob" or "USB Dildo" and any of them works to sign in.

Once signed in you can remove any you've lost or stopped using, and add any new ones.

The keys themselves have no idea where you used them (at least, affordably priced ones, you could definitely build a fancy device that obeys FIDO but actually knows what's going on rather than being as dumb as a rock) and there's no reason for your software like a browser to record it. Crypto magic means that even though neither browser nor key remembers where if anywhere you've registered, when you visit a site and say "I'm munchbunny, my password is XYZZY" it can say "You're supposed to have one of these Security Keys: Prove you still do" and it'll all just work.

[munchbunny]

Thanks for the explanation. It all makes sense, and the public/private key system is awesome for that.

The point I was getting at was "if your one Yubikey is stolen, what do you do?" If you fall back on password authentication, then your Yubikey based system was only as secure as the password mechanism protecting your account recovery mechanism.

The answer might be "provision two keys and stick one in a bank deposit box", etc. Regardless, there's an inherent problem that you want your recovery mechanism to be as hard to crack as your primary authentication mechanism, but you need it to not be an absolute pain.

[jwr]

Most sites require you to set up another form of 2FA along with U2F (for example, TOTP using Google Authenticator). There are also recovery codes that you print and store on paper.

I don't consider losing a Yubikey to be a serious problem, though it's important not to use it to generate RSA keys, as then you will not be able to make any backups. Generate your keys in GnuPG and load them onto the key, keeping backups in secure offline locations.

[tialaramex]

Several of the sites offering 2FA begin by telling you a bunch of arbitrary one-use passwords for such emergencies. They suggest you write _those_ down and stash them somewhere.

They also tend to propose you provision several other 2FA mechanisms, such as SMS or TOTP OTP. But yes, I always begin by enrolling two Security Keys, and then one of them goes back in my desk drawer of emergencies.

[palisade]

Potentially difficult if you were relying on a unique product like yubikey which doesn't have a 1 to 1 competitor in the industry at the moment.

[vel0city]

There are many makers of FIDO U2F complaint hardware devices these days.

[palisade]

The original poster was discussing the OpenPGP feature. The U2F feature of YubiKey wasn't compromised by the vulnerability.

The vulnerability is real and still exists. There was even someone in this HN thread that was planning to use an old key fob Arstechnica sent him, specifically for the OpenPGP feature.

I should have split my backup and vulnerability comments into two, because they've sparked two unrelated debates. It started out as such a simple comment! :)