I mean, that's the security story around it. You solve this and buying multiple yubikeys. Google and others support multiple keys, which gives you the backup story (I have 4 keys in various places).
There's no fundamental reason it needs to be this difficult.
Yubico or really any other manufacturer could totally e.g. release "Yubikey pairs", both a stateless CTAP2 implementation with the same root secret, that would correspondingly work at the same sites without having to synchronize anything.
The reason they probably don't is that their entire trust model heavily depends on the perception that nobody, including the manufacturer, has a "reserve key" to any given Yubikey, even though of course the absence of such "linked keys" doesn't demonstrate the absence of any such backdoor.
To be clear, I don't have any reason to believe Yubico does this, but it would probably be a harder story to tell, marketing-wise, if they sometimes selectively did, even if it's for a valid use case.
I mean you could also design keys to be synchronisable by the user. Generate a key-pair inside of key (2), transfer the public key from (2) to (1). Encrypt the the root key inside of (1) with the public key, transfer it over to (2).
(Or just allow the user to generate the root key outside of the device and insert it)
I honestly think the interest from customers is just too low. I would bet the majority of Yubico's customers are enterprises where this is not really an issue for most use cases. If you loose your key used for Entra ID / SSO, just go to IT support and get a new one enrolled to your account. Much cheaper than having synchronised hot spares (at 30-50 USD a pop) for thousands of employees.
But what stops Mallory from simply using this sync method to sync your private key to her Yubikey? I mean, look at the kerfuffle that's been kicked up by this vulnerability, and a key-sharing scheme like the above is much easier to exploit.
(The second idea seems better assuming the user nukes the private key once the import is done. Otherwise the weakest link in the security chain will continue to be the opsec you practice with the private key file, in which case why spend the money on the Yubikey?)
Yeah of course the operation needs to be (cryptographically) authenticated somehow, I edited my comment in haste while going to work and accidentally messed it up completely. Thanks for pointing it out!
The idea I thought of is to essentially use the public key of (2) to seed the generation of the root secret on (1). Meaning the sync-pairing-setup is destructive to the root secret, and can only be done at startup (or if you are willing to reset the device).
(A mallory could of course reset it still, unless you have some e-fuse or something, but anyways that's only marginally worse than simply physically destroying it.)
> (A mallory could of course reset it still, unless you have some e-fuse or something, but anyways that's only marginally worse than simply physically destroying it.)
You can already reset CTAP2-compliant FIDO keys using a (non-PIN-authenticated) command [1], so this wouldn't add anything that isn't already there.
I think the real issue here is that users probably don't expect having to reset/initialize a Yubikey once they take possession of it. Given the horror stories of how e.g. Amazon commingles inventory, I wouldn't be surprised if fraudsters could succeed in getting paired keys back into the supply chain.
Targeted attacks to friends/family can probably also not be ruled out ("hey, i got this spare yubikey in a black friday sale, want it?"), and unfortunately something like a family member or partner trying to take over somebody's accounts isn't unheard of.
There are just too many ways for this to go wrong, and while Yubikey has, I believe, looked into this option in the past (there's a draft design doc for this idea somewhere), they probably came to the same conclusion.
> You can already reset CTAP2-compliant FIDO keys using a (non-PIN-authenticated) command [1], so this wouldn't add anything that isn't already there.
Ah I did not know that, thanks.
> There are just too many ways for this to go wrong, and while Yubikey has, I believe, looked into this option in the past (there's a draft design doc for this idea somewhere), they probably came to the same conclusion.
Would be interesting to see the draft. But yes of course, there are tradeoffs. Having a LED similar to on the Bio to indicate it's paired could be one way, or selling pairs in a SKU where the user actually have to initialise them (with some clear physical difference to help solve the family/friends case). But it's complicated, and I think Yubico has made the correct decision that it's simply not worth it (not that it's impossible to do in a secure way).
However, the lack of a resonable backup solution is keeping me away from Yubikey for any non-enterprise use, where a broken key would actually lock me out of an account for real.
HSMs support these kinds of scenario (high availability clusters, wrapped keys etc) but I agree. For enterprise use there's no interest or need, and for end users the feature would potentially be confusing.
I just use multiple tokens, and I knew that the infineon sle78 was an intel 80251 derivative before this report ;)
True, but what's even more convenient than that is to just not use hardware authenticators for anything but the most important accounts/sites, and e.g. use syncing credentials (as provided by many password managers, Google, and Apple).
The fraction of people willing to regularly schedule enroll-o-ramas at each of their accounts and each of their backup key locations is probably smaller than a percent of all potential WebAuthN users.
It is really annoying that more sites don't support multiple security keys, though. As far as I can tell, it's not encouraged by the FIDO Alliance and I can't think of a good technical reason for it.
I forget which financial institution I was using at the time, but they explicitly only supported one key. That is, you add a new one and the old one is expunged.
Banks are so slow with this sort of thing, and still require SMS as a fallback option.
The vast majority of sites I've used Yubikeys for have supported multiple. About the only one that I use which still doesn't to my knowledge is Paypal.
Maybe I'm out of date, then! I don't enroll new keys very often. Paypal is a great example of a service that I would like to support multiple keys, though, so it's disappointing that they still only support one.
How often do you check to see that those other/backup keys are still secure? This attack becomes easier if the attacker knows of the secondary key(s) location and because of disuse they aren't even necessary to replace.
I mean, not all at once, but (I only have 3) there's the one when I bought a new laptop in 2019 which I setup when I got that laptop and became the old one when I got a new laptop in 2021 and setup a second one. And then the third one is a backup key I made at some point and is stored offsite in case I/my house gets robbed/burgled or my place burns down in a fire.
It's inconvenient, sure, but it's more convenient than my bank accounts that are accessible online being cleaned out.
