3 ms·

The thing that makes me a bit jumpy about hardware 2FA with things like this or a Yubikey is around what happens if I lose it or it breaks. It's not so much a

The thing that makes me a bit jumpy about hardware 2FA with things like this or a Yubikey is around what happens if I lose it or it breaks. It's not so much a problem in a corporate setup (like internally at Google) where you could go to a central admin team to revoke/replace the key. But if you're a home user using this for a wide variety of sites and the token fails then the failure mode seems to be "go figure out the fallback for every site you use and use that", which could be really painful. I prefer the, possibly less secure but more flexible option of TOTP applications that let me synch to multiple devices, so the loss of one device isn't very painful.

pentestercrab 8y ago
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.
bertil 8y ago
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.
suixo 8y ago
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...
simias 8y ago
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.
moviuro 8y ago
See https://twofactorauth.org/ 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).
chillydawg 8y ago
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.
- raesene9 8y ago
  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?
  - chillydawg 8y ago
    When you buy one and follow the basic setup steps it tells you how. Always buy them in pairs.
oxplot 8y ago
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.
- raesene9 8y ago
  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.

pentestercrab 8y ago

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.

bertil 8y ago

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.

suixo 8y ago

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...

simias 8y ago

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.

moviuro 8y ago

See https://twofactorauth.org/ 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).

chillydawg 8y ago

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.

raesene9 8y ago
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?
- chillydawg 8y ago
  When you buy one and follow the basic setup steps it tells you how. Always buy them in pairs.

oxplot 8y ago

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.

raesene9 8y ago
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.