[unknownsavage]

This is really awful, for it to work well you would need to buy multiple keys and each time use them all to register (which precludes the option of storing the backup key somewhere safe).

Straight from the yubico website: "It is recommended that users register at least two U2F devices with every service provider should a U2F device be misplaced"

That's just a plain usability nightmare, and not to mention expensive.

The trezor one works a lot more sanely for u2f, you get a recovery key when you first set it up (it uses the screen to output it, so even if your computer has malware it can't be compromised) and can leave it in a safe at your friends place.

[tptacek]

Part of the point of hardware tokens is that you can't back up and restore their keys. If backup and restore is important to your userbase, you should stick with soft tokens.

[jeff_marshall]

I disagree that it's undesirable for back-up and restore to be impossible in all cases.

Instead, I would argue that plain-text export of private and secret keys is undesirable, as it removes any protections the HSM was supposed to provide (2 man rule for access, audit of use, etc). Back-up schemes that export these keys (in encrypted form) to another HSM that enforces the same rules as the original HSM can be useful, IMO.

[tptacek]

I wouldn't personally recommend backing up and restoring 2FA secrets; there's a reason that the printable backup codes you get are one-time-use. But if you're going to do that, don't bother with hardware tokens. I mean, use them if they make you feel cool (I'm not being derisive; there's value in feeling better), but understand that you're effectively turning your hardware token into a software token by doing that.

My point is not that backup and restore is intrinsically evil; it's a legit security/usability tradeoff. I think most people should use software tokens.

[samatman]

Could you elaborate on this, please? It's contrary to my intuition, and I respect your opinions on the subject. Having an auditable hardware token shouldn't preclude backup and restore? It still reduces the surface area for vulnerabilities to an object with no radio.

[tptacek]

I'm worried at this point that I'd be repeating a comment I've made on this branch of the thread, so can I ask if you have any questions about those responses?

[unknownsavage]

The trezor only lets you backup the key during the initialization stage. After that the key can never be recovered. Also you can set a password so it's encrypted as well, so even if someone finds your paper backup it's not particularly useful.

[tptacek]

If there can at some point in time be two or more tokens with the same secrets in them, you're essentially parked in the same security place as soft tokens. Just use the soft tokens.

I'm not saying soft tokens are bad. They're not; they're great. When we get a workable U2F software token, that might be the best option for most people.

What I'm saying is don't spend money on a hardware solution that isn't buying you any meaningful additional security.

[j_s]

Can you recommend any soft token U2F implementation, especially if there's different "best" ones per-platform?