The cons about 2nd-U2F device seem rather odd. Several boil down to "houses aren't secure", but the primary attack vector for the vast majority of users is not physical invasion or destruction of their home. Similar concerns are raised for recovery codes.<p>For OTP, calling it out as "non-universal" seems strange: far more services support TOTP/HOTP than U2F at the moment, so for most users, even if they use U2F everywhere it's available, they'll still end up with a pile of TOTP codes on their phone.<p>The proposed solution is even more strange: it still recommends storing the 2nd token at home, but offers to solve registration of new services while abroad. No solution is provided for improving recovery beyond just using two U2F tokens.
Wat.<p>The cons listed on "Separate U2F token for backup" doesn't make any sense (except the last point, I'm looking at you, twitter). They assume that you have your primary u2f token on your keychain and backup token at home or in a safe. That's nonsense. You should have one nano u2f token in every laptop's usb port, then another one on your keychain (and probably another one at home or somewhere). And there's no primary/backup. Every u2f token should be treated the same.
Notably, Twitter doesn't support adding multiple U2F keys.<p>The current state of USB ports makes it really important to be able to add multiple keys to an account. From my experience you need 1) USB A key that are used on most devices, 2) USB C keys that can be used on devices like MVP, 3) NFC keys to work from your Android device.
I don't believe the Yubikey is the problem as much as the U2F spec. Public key crypto solves this nicely, because one can carry all the public keys and only a single private key. When I think of backup keys, I think multiple keys, not duplicate keys. Having a duplicate of the U2F key is a bigger problem for security than those outlined here. Being unable to duplicate the Yubikey is a feature, not a bug.
I'm no u2f expert (actually this article gave most of my knowledge about u2f) but imho there's a small security problem?<p>The author says:<p>"This way, the counter range of the primary token is [0, 2097151], while the counter range of the backup is [2000000000, 2002097151]. The fact that those ranges don't intersect ensures that once backup token is used on some service, the primary one is invalidated for good."<p>But... If my understanding is correct, the counter value is stored both on the server and the token. The server rejects authentication IF the value of counter provided is less than the value of counter stored server-side.<p>This means that every server (service) stores a different value of the counter.<p>Doesn't this mean that using the backup token only invalidates the main token for the single service for which the backup token it's being used?<p>The main (compromised) token will stay perfectly usable on all the services except for those where we manually disabled the main (compromised) token.<p>Am I correct in this?
Incidentally I was talking to Conor about this problem yesterday.<p>This post, in very short, proposes to flash two devices with the same key. I think this is great for hackers & makers, but not for consumers.<p>Moreover, it might be convenient on a superficial level, but I think it's fundamentally useless. If we consider the security model, the backup device can only be used if the primary device is damaged. If the primary is lost or stolen, the key should be invalidated, and thus the backup device is useless.<p>This means that you always need 2 distinct, active security keys anyways.
So basically U2F clones. It would be neat to have some sort of CA between U2F devices, device A could sign device B and be put away, and device B could store the signing and share that with sites. This would allow device A to revoke device B completely, but would require a change of u2f support.<p>I understand the counter piece, but let's say someone steals your primary U2F, can't they just increment the counter to 1000002 and it would keep working even if you have used your backup token?
I don't see the point. I have 4 U2F tokens, 1 I keep on my person, 1 I keep at home, and 2 in other safe places. The only downside is if I lose I token I then have to log into all my online accounts which support U2F to update my list of tokens.
nice and obvious after reading (a good quality).<p>he fails to recognize that the yubikey has a secure element and is actually secure, whereas the u2fzero is garbage. (secure vs the host OS but otherwise trivially hacked).<p>he is worried about losing his phone — which is relatively secure — to the degree that he’d have to invalidate all the keys, yet for the less secure u2fzero has no such concern.<p>a better solution would be a cloud backed token. (still with caveats of course)