[EvanAnderson]

Two factor tokens that can't be backed-up create stupid make-work.

Wouldn't it be great if Yubico let you back-up and restore a Yubikey?

It's maddening that they haven't come up with a reasonable way to allow a purchaser to register multiple Yubikeys to enable freely restoring backups between them. (Think of if analogously to buying multiple padlocks keyed the same from the factory.)

I'd prefer to be able to just set the same DKEK on the devices myself. Failing that I'd settle for Yubico being the arbiter. It would make the devices substantially more useful and less scary in loss / destruction scenarios.

[Citizen8396]

If the secrets are routinely copied or otherwise extracted, then it reduces their security value. What I recommend people do is buy two or more and set them up all at the same time. It is inconvenient though.

[EvanAnderson]

I suppose I should have preemptively made that argument and then argued against it.

My point is that there should be a mechanism to extract key material in an encrypted form. The backup could only be restored onto properly-prepared hardware (either by way of a device master key held under escrow by Yubico, or by an initial "seed" set by the user when commissioning the hardware).

Setting up multiple keys at the same time isn't just inconvenient, but actually defeats the purpose of backup. If both keys have to be present in the same place at the same time it's not a backup.

The workflow with tokens that can't be backed-up creates needless labor and risk. HSM vendors have solved this problem (albeit with tremendous vendor lock-in) but apparently that's too difficult for consumer token vendors to handle.

[Citizen8396]

This adds complexity and the added questions of how much you really trust vendors to handle it correctly.

After setting them up, I store one or more at various other locations. The core services people use them for rarely change, and adoption outside of those important services is slow. Even if you only kept one at home and one on your person at all times, this might mean a key would survive something like a house fire.

If given the choice between a hardware token and a passkey, I would prefer the former since it is almost impossible for it to be tampered with (especially without physical access to it).

I do see your point about HSMs and see why people would want such features (especially if there are multiple interested parties involved).

[EvanAnderson]

> The core services people use them for rarely change, and adoption outside of those important services is slow.

That's the opposite of what would be good for general security, though. I want people using these devices for as many services as possible. Heck, I even enjoy the FIDO workflow when I've used it in corporate settings (where I have a recovery method that doesn't involve begging a FAANG company to please, please, please give me back access to my stuff). I would love to use it for personal stuff instead of mucking with a password vault, TOTP, etc.

I guess the argument could be made for using these devices only w/ your "digital feudal lord" of choice (Google, Microsoft, Facebook, etc) with the expectation that all other services you use would federate authentication with those various fiefdoms. I don't see that happening with banks, for example. (Banks would be a great example of a place where I'd want to see token-based authentication adopted. I am so goddamned tired of SMS "authentication" being used w/ to arbitrate access to my money.)

I also find the idea of companies federating their authentication with the big digital feudal lords, to the exclusion of local authentication, repugnant.

My problem w/ tokens as they are now comes down to the "you must have both tokens in the same place to enroll new accounts" workflow being bogus. It creates make-work for people. Any technological "solution" that creates make-work for people is wrong, full stop. For me this workflow would discourage using the token in favor of technologies I can back-up (like passwords and TOTP seeds). For "normies" people are just going to lose their tokens and be in account recovery hell.

Here's my pitch for how I think it could work:

Token vendor sells a very simple embedded device to "brand" tokens. The device has no communication capability beyond a display and a USB port to connect tokens. This "branding iron" is enrolled w/ a vendor-signed certificate at the factory. The tokens are probably already enrolled w/ a vendor-signed certificate at the factory. This establishes a root of trust for the tokens and the "branding iron". I don't have to trust the vendor for anything more than a hardware root of trust.

The end user would use the "branding iron" to create a master key and enroll it onto their tokens. The ergonomics are very important but, functionally, it's just spinning a suitably large random key, showing it to the user so they can make an offline copy, and loading that key onto tokens. There are a ton of ergonomic decisions to A/B test (does it have a PIN pad, does it use a Bitcoin wallet-style key phrase presentation method, etc), but the functional purpose is simple.

The user would plug their tokens into the "branding iron", which would wipe them clean and, using the root-of-trust shared between the devices, load the master key into all the tokens.

This makes encrypted backups portable between tokens. The backups could be stored anywhere. (I like the idea, since a lot of tokens are HID keyboards, of just having the token "type" the backup into an email or a text file.)

[pabs3]

Passkeys can be if you use KeePassXC to generate and store them.

[TacticalCoder]

> It's maddening that they haven't come up with a reasonable way to allow a purchaser to register multiple Yubikeys to enable freely restoring backups between them.

It is possible, using a cryptocurrency hardware wallet allowing to install tiny apps on the hardware wallets. These wallets are meant to initialized by a "seed" and there's a protocol to easily write down that seed (a list of words, all coming from a dictionary of 2048 words and the list of words contains a checksum in [part of] the last word).

Now from that seed, cryptocurrencies hardware wallet can derive any secret. And it's possible to derive a secret that's used like Yubikey.

So as long as you have your "seed" backed up somewhere, you can duplicate your 2FA key.

I did test the old U2F version, pre FIDO2/webauthn, using early Ledger Nano hardware wallets and it worked.

I think there's now a more recent version available but haven't checked that. A Ledger Nano S Plus, from their website, costs 70 EUR / 80 USD. I'd say it's not too pricey to try it and see if it could suit you. Check their available apps first and see if there's one that can simulate a Yubikey (or a similar 2FA security key).

I know HN loves to hate on cryptocurrencies but I'd say that at least the crypo-bros got the "you cannot trust your computer" part right. The attack surface of a cryptocurrency hardware wallet is not only minimal: it's minimal on purpose, built on the premises that computers were not devices to be trusted. They're literally built with the idea that they can be used on a compromised computer and you should still be safe, so there's that.

[EvanAnderson]

> ... These wallets are meant to initialized by a "seed" and there's a protocol to easily write down that seed...

Yes. That's a thing with some HSMs, too. That's where I've had experience with this kind of protocol.

As it stands Yubico's tokens are unusable to me for personal purposes because they can't be backed-up and restored.