I think I'd like a version of this scheme which works a bit like email-based verification: you have a trusted provider (like an email provider today, you can self-host or use any of the many 3rd party hosts) that you use to vouch for your identity. When you want to log into a website you use a certificate authenticating you, the website checks if it's valid with your authority (similar to the current email-based verification on most websites). If you want to change your certificate for any reason you only have to do it with your authority and everything else keeps working as usual. The drawback of course is that you have a single point of failure, if the authority is compromised you're naked in the wild.

IIRC OpenID worked like that but unfortunately it never gained traction. It's a shame really.

More practically I do use a yubikey myself but mostly as a GnuPG smartcard, not for 2FA. I actually have the same key stored on multiple tokens as a backup, so if my current key breaks I just have to fetch an other one. Of course if instead I lose it or it's stolen I'll probably have to generate new keys (even though the PIN should theoretically still protect me) so the problem still exists.

See https://twofactorauth.org/ . I thought there was an ongoing effort to add backup/restore steps to this informative site.

Indeed, I was recently locked out of some of my accounts: I used some "one-shot backup codes", but some sites didn't deliver them (and so, required involvment of admin/support by mail+phone).

With yubikeys, you can effectively clone them when setting them up initially. So you carry one and keep another spare in a safe location. If your primary fails, you can buy another and promote your hot standby to primary having set the new one up to be a clone.

Ahh that is interesting! Do you know is there a doc. on how that's done? Also does that mean that once the clone is done you can effectively just register once with your "live" key and if it fails seemlessly use the "backup" key or do you need to register with both for that to work?

When you buy one and follow the basic setup steps it tells you how. Always buy them in pairs.

For both cases, what you want to have is a central account that you authenticate to using the key, and that account uses OpenSocial/OAuth-like protocols to grant access to separate services.

That’s how those central teams manage to revoke keys easily.

In the original U2F spec, I think there was an "answer" to this revocation issue: "enroll a second device for every origin, and keep this one in a safe". This way you can still connect even if you lose the first one.

In practice, well, meh...

If you want U2F with recovery, the Trezor from SatoshiLabs is a great option. Only issue is the cost is a bit higher than most hardware tokens.

umm, buy two, enroll both and keep one safe somewhere?

I'm very surprised when people voice this concern. These keys cost a mere $20 or so. There's no limit to how many website you can set them up with. So $40 or even $60 is all you need to invest in.

It's interesting you say that, does that not mean you need to enroll both keys on every site you use them on?

This makes having one in a safe location somewhere kind of tricky, as it has to be accessible when you're signing up. so for example if you're travelling/working from another site, you won't have your "safe" key to hand.

Also you need to remember to do the enroll twice for every service, forget one, and you're back to trying to see if there's a fallback procedure.