8 ms·

Reliable, Secure and Universal Backup for U2F Token

46 points by dimonomid 8y ago

akerl_ 8y ago
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. 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. 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.
- dimonomid 8y ago
  I don't know what makes you miss the point, but ok, let me repeat. With the regular second U2F device it has to be easily accessible (e.g. at home in my sleeping room). With the proposed solution, it doesn't have to be easily accessible. > it still recommends storing the 2nd token at home In the article I mention that I can either bury it somewhere in the forest or brick up into the wall. Even if we ignore the forest part, do you consider "bricking up into the wall" and just keeping in sleeping room as the same thing, even it's my home's wall? If you do, then ok, sorry for wasting your time, we're not going to agree. Because I believe that making the token really hard to access (like having to disassemble the actual wall a little bit) does make the token a lot more secure. And another important point that with the regular token I have to add it to every new service manually. Which can be not trivial if I'm traveling far from home. And I can just forget, etc etc.
  - akerl_ 8y ago
    If someone is in my home looking for my U2F key, they've bridged the gap between the threat model I'm concerned with and the model where they're clearly motivated enough that putting the key in brick isn't going to stop them. Furthermore, I don't really like the prospect of having to take a sledgehammer to my wall when I drop my U2F key during a trip. Personally, I have a couple U2F tokens and OTP on my phone, with recovery codes. If I register for a new site when I'm on the road, it gets my travel U2F and phone OTP. When I get home, I pair up the 2nd U2F and drop the recovery codes in the box with the rest of them.
    - dimonomid 8y ago
      First, if the token is easily accessible, then they can steal it even if they don't actually look for it. Like, steal "accidentally". Second, obscurity here is an important part of the security: you don't have to tell anyone that you have a token in the wall, so even if they came specifically for the token, they can surely look for it in your home (because the majority of people store backup token just at home), but it's a lot less likely that they start break walls (unless they specifically know it's there). So here, the level of security is up to the token owner. As to having to take a sledgehammer: well, losing a token is an emergency situation and I just try hard not to lose it. But if I do, I still have a way out, and breaking a wall a little is still a lot better than losing the access to my accounts.
- nickray 8y ago
  Yes, the vast majority of users just worry about losing or breaking their U2F token. Such a user just wants to be able to log in and replace credentials. The proposed solution, which I find surprisingly elegant, in comparison to regular two tokens offers ease of use: avoiding registering a second token everywhere (and possibly the invalidation of the lost key at first login). Compared to the usual TOTP fallback, it keeps the phishing protection.
  - dimonomid 8y ago
    Thanks. What do you mean by "possibly" though? > and possibly the invalidation of the lost key at first login Do you mean that some service might disregard the counter value (the fact that Google and Github respect it doesn't mean everyone does the same), or something else?
    - nickray 8y ago
      Yes :) Personally, I would just start replacing credentials upon loss in descending order of importance.
      - dimonomid 8y ago
        Yeah sure, I mentioned in the article that the purpose of the backup is to enroll a new token and revoke the old one. It would be a bad idea to keep using backup for a long time anyway.
yegle 8y ago
Notably, Twitter doesn't support adding multiple U2F keys. 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.
- dimonomid 8y ago
  Oh, thanks for the note about Twitter! I'll update the article.
nmca 8y ago
Are there really no commercial products that support this? I'd be keen to buy one that did, current fallbacks seem fairly crazy by comparison.
- dimonomid 8y ago
  Not that I'm aware of. I wrote to Yubico and surepassid, both said it's not possible.
- nickray 8y ago
  I am considering adding this to my European distribution of U2F Zero, but the problem here is that as the vendor I then know your secret key. As mentioned in another comment, the uncloneability of Yubikeys is a feature (similar to Google Authenticator vs Authy).
  - ecesena 8y ago
    What do you think about a protocol like: https://news.ycombinator.com/item?id=17770803 https://news.ycombinator.com/item?id=17770803
jiveturkey 8y ago
nice and obvious after reading (a good quality). 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). 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. a better solution would be a cloud backed token. (still with caveats of course)
- dimonomid 8y ago
  In which way u2fzero can be trivially hacked?
  - jiveturkey 8y ago
    The ATECC508A is not used correctly. It is used as a RNG and for it's crypto functions, but not for key storage. So any site's key is trivially extracted with physical possession of the device. The wrapping key is also extractable, therefore you only need one-time offline possession of the device. The source code is horrible so I'm not going to do a full analysis but that's the gist. A recent generation phone is far, far more secure.
    - dimonomid 8y ago
      > The ATECC508A is not used correctly. It is used as a RNG and for it's crypto functions, but not for key storage. Where did you get that idea from? Preparing a device consists of the following steps: - Flash temporary configuration firmware - Send keys to the device, which are stored on ATECC508A - Flash actual u2f-zero firmware So on the second step (configuring the device), the host writes keys on the device, and those keys are stored on ATECC508A. It happens there: https://github.com/conorpp/u2f-zero/blob/master/firmware/src/atecc508a.c#L568 https://github.com/conorpp/u2f-zero/blob/master/firmware/src... I do agree that the code is bad though, but alas. I did consider reimplementing it properly, also on a more powerful chip, but I don't think I'll be able to find time for that. Anyway, dirty code doesn't mean that the device is insecure. From what I see, among other things, ATECC508A is used properly.
dokument 8y ago
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. 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?
- dimonomid 8y ago
  There's no easy way to increment the counter, so one would have to invent some automation for sending authentication challenges to the token and pressing the physical button every time. The time it'd take should be enough for me to get another pair or tokens, enroll it to my accounts and revoke the old one. Also let's make it not 1 000 000 but, say, 4 000 000 000, which still leaves plenty of values of a 32-bit value.
- jiveturkey 8y ago
  > let's say someone steals your primary U2F, can't they just increment the counter to 1000002 If they steal a primary yubikey token, no. The counter is stored and managed only in the secure element part of the device. If they steal a primary u2fzero token, which of course the proposal depends on, the counter is not protected in any meaningful way. This doesn't matter in practice, however. No site is doing anything useful with the counter.
  - dimonomid 8y ago
    > No site is doing anything useful with the counter. What do you mean? In the article I mentioned that at least Google and Github refuse to authenticate if the counter is less than the last seen value. So using backup token does invalidate the primary one. > If they steal a primary yubikey token, no. The counter is stored and managed only in the secure element part of the device. If they steal a primary u2fzero token, which of course the proposal depends on, the counter is not protected in any meaningful way. Where did you get the idea that the counter on u2f-zero is not protected in any meaningful way? The counter is maintained by the ATECC508A chip and is incremented on each authentication. And also see my adjacent comment about reliably preventing primary token from returning a counter which is as large as that of backup token.
fishywang 8y ago
Wat. 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.
- nickray 8y ago
  Should? That does mean: purchasing a bunch of tokens, each of which could be lost, and registering them all. I don't think online security has normative/prescriptive rules, just tradeoffs :)
danjoc 8y ago
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.
- dimonomid 8y ago
  > Having a duplicate of the U2F key is a bigger problem for security than those outlined here. So, what security problems come to your mind if we consider a duplicate token buried at 1 meter somewhere in the forest (and nobody really knows where it might be) ?
  - danjoc 8y ago
    My key is stolen. I have to revoke it, but I need my duplicate to log in to do it. The attacker stole my key and phone, because they were in the same place. I've only got a few minutes to go out to the remote forest and dig a meter down to find my key before the attacker uses it with the phone back at bad guy headquarters to launch the nukes. Did I bury it next to this tree or that one? Damn it, they all look the same now. Dig fast, but careful not to smash the key with the shovel. Gosh, the water table is higher than when I buried it. I hope it still works. Christ, it's all tangled in roots! Pull!! Got it! Now log in, revoke it, reflash the key, re-enroll. Phew! Humanity is saved. With PKI, I contact my spouse. Honey, can you revoke the key I'm carrying? It's been stolen. Thanks sweetie! See you tonight. I'll admit the duplicate approach makes for a much better movie. The PKI solution is positively boring. Maybe we could throw in a spouse kidnapping to keep it interesting?
    - dimonomid 8y ago
      Ah ok, I see what you mean. So can we use the PKI solution today to use as a second factor for, say, Google?
      - 8y ago
ecesena 8y ago
Incidentally I was talking to Conor about this problem yesterday. 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. 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. This means that you always need 2 distinct, active security keys anyways.
- ecesena 8y ago
  Assuming there's a real case where you want a backup, i.e. you fear physical damage, but don't fear lost/stolen. For consumers, I believe that the distinction between broken vs lost/stolen is very hard to explain. Think also to a company where you deploy security devices. An employee suddenly needs a backup device. Helpdesk should investigate if it was broken, or lost. It's simply a mess. For a possible solution, I think there should be a protocol where a user can export the key, encrypted for a backup device. At a high level: 1) insert the backup device and start the backup process, this export a public key, proof of possession of the corresponding private key, attestation certificate 2) insert the primary device, export the key: upon validating attestation and proof of possession, encrypts the key for the backup device and export the blob, 3) re-insert the backup device to receive the key, decrypt, store and use it. Since this moment on, the device should clearly look as a backup, for example the led could be red instead of blue (see, for example, how MetaMask displays imported keys). I don't think the protocol is really important here, I think what's really important is that: 1) the user should be the one creating the backup device, if he's knowledgeable enough and understands the risks and uses, and 2) most importantly, there shouldn't be a way to flash a security device with untrusted code. I'd be curious to hear what people think about this, would backup be useful to you? We're working on the new gen of u2fzero (https://solokeys.com https://solokeys.com), and this could be a nice feature to add if people feel it's needed.
  - jiveturkey 8y ago
    There's no advantage to your method vs programming the same wrapping key into both devices. As far as the site is concerned, these are the same device but with different counter streams. I mean, yes the 2 devices can be initialized at different times, but otherwise it makes no matter.
znpy 8y ago
I'm no u2f expert (actually this article gave most of my knowledge about u2f) but imho there's a small security problem? The author says: "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." 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. This means that every server (service) stores a different value of the counter. 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? The main (compromised) token will stay perfectly usable on all the services except for those where we manually disabled the main (compromised) token. Am I correct in this?
- znpy 8y ago
  There should be a way to invalidate a token on all services in a single time. Maybe service providers could provide an https endpoint to perform this? It might be a good idea to give a distinct well-known name to this kind of endpoints, and provide such endpoints in the registration email so that when a token is to be invalidated, an user can regexp-search the well-known name of the endpoint in their mailbox, retrieve all such endpoints and invalidate the compromised token against all of them.
  - jiveturkey 8y ago
    > Maybe service providers could provide an https endpoint to perform this? That's a good idea, with one caveat. It needs to be quite hard to revoke a token. Proof of 1-factor is not sufficient; an attacker could then simply revoke your token and then gain access. So a lost token is quite a challenge, even if there is a revoke URL. This doesn't seem automatable (to revoke all "in a single time" as you say). > provide such endpoints in the registration email In addition, the browser should record U2F interactions and know all sites on which a token was registered. Then such a list is very easily accessible, as long as the browser log is available. If it isn't, well you have email as a backup log. The fact that you can't unilaterally revoke all token registrations is the main weakness of U2F. (besides the cost and the user action required for uptake of it)
chaz6 8y ago
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.
- dimonomid 8y ago
  Ok cool, so whenever you register on a new service, you have to add all 4 of them, which means going to "other safe places", picking tokens, adding them, and placing them back. Also I doubt your safe places are as safe as bricking them into the wall. Apparently it's okay for you, so, keep it up then. I personally hate this. Also having 4 tokens does feel kinda too much to me. Each additional device does open a new attack vector, and if your token at home or in other places suddenly disappears, you're unlikely to even notice that quickly, while an attacker could use that time having a token. Also, if the service doesn't support having multiple tokens (as mentioned in comments, Twitter is such an example), then having 4 tokens doesn't help much.

46 points by dimonomid 8y ago

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

dimonomid 8y ago
I don't know what makes you miss the point, but ok, let me repeat. With the regular second U2F device it has to be easily accessible (e.g. at home in my sleeping room). With the proposed solution, it doesn't have to be easily accessible. > it still recommends storing the 2nd token at home In the article I mention that I can either bury it somewhere in the forest or brick up into the wall. Even if we ignore the forest part, do you consider "bricking up into the wall" and just keeping in sleeping room as the same thing, even it's my home's wall? If you do, then ok, sorry for wasting your time, we're not going to agree. Because I believe that making the token really hard to access (like having to disassemble the actual wall a little bit) does make the token a lot more secure. And another important point that with the regular token I have to add it to every new service manually. Which can be not trivial if I'm traveling far from home. And I can just forget, etc etc.
- akerl_ 8y ago
  If someone is in my home looking for my U2F key, they've bridged the gap between the threat model I'm concerned with and the model where they're clearly motivated enough that putting the key in brick isn't going to stop them. Furthermore, I don't really like the prospect of having to take a sledgehammer to my wall when I drop my U2F key during a trip. Personally, I have a couple U2F tokens and OTP on my phone, with recovery codes. If I register for a new site when I'm on the road, it gets my travel U2F and phone OTP. When I get home, I pair up the 2nd U2F and drop the recovery codes in the box with the rest of them.
  - dimonomid 8y ago
    First, if the token is easily accessible, then they can steal it even if they don't actually look for it. Like, steal "accidentally". Second, obscurity here is an important part of the security: you don't have to tell anyone that you have a token in the wall, so even if they came specifically for the token, they can surely look for it in your home (because the majority of people store backup token just at home), but it's a lot less likely that they start break walls (unless they specifically know it's there). So here, the level of security is up to the token owner. As to having to take a sledgehammer: well, losing a token is an emergency situation and I just try hard not to lose it. But if I do, I still have a way out, and breaking a wall a little is still a lot better than losing the access to my accounts.
nickray 8y ago
Yes, the vast majority of users just worry about losing or breaking their U2F token. Such a user just wants to be able to log in and replace credentials. The proposed solution, which I find surprisingly elegant, in comparison to regular two tokens offers ease of use: avoiding registering a second token everywhere (and possibly the invalidation of the lost key at first login). Compared to the usual TOTP fallback, it keeps the phishing protection.
- dimonomid 8y ago
  Thanks. What do you mean by "possibly" though? > and possibly the invalidation of the lost key at first login Do you mean that some service might disregard the counter value (the fact that Google and Github respect it doesn't mean everyone does the same), or something else?
  - nickray 8y ago
    Yes :) Personally, I would just start replacing credentials upon loss in descending order of importance.
    - dimonomid 8y ago
      Yeah sure, I mentioned in the article that the purpose of the backup is to enroll a new token and revoke the old one. It would be a bad idea to keep using backup for a long time anyway.

yegle 8y ago

Notably, Twitter doesn't support adding multiple U2F keys. 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.

dimonomid 8y ago
Oh, thanks for the note about Twitter! I'll update the article.

nmca 8y ago

Are there really no commercial products that support this? I'd be keen to buy one that did, current fallbacks seem fairly crazy by comparison.

dimonomid 8y ago
Not that I'm aware of. I wrote to Yubico and surepassid, both said it's not possible.
nickray 8y ago
I am considering adding this to my European distribution of U2F Zero, but the problem here is that as the vendor I then know your secret key. As mentioned in another comment, the uncloneability of Yubikeys is a feature (similar to Google Authenticator vs Authy).
- ecesena 8y ago
  What do you think about a protocol like: https://news.ycombinator.com/item?id=17770803 https://news.ycombinator.com/item?id=17770803

jiveturkey 8y ago

nice and obvious after reading (a good quality). 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). 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. a better solution would be a cloud backed token. (still with caveats of course)

dimonomid 8y ago
In which way u2fzero can be trivially hacked?
- jiveturkey 8y ago
  The ATECC508A is not used correctly. It is used as a RNG and for it's crypto functions, but not for key storage. So any site's key is trivially extracted with physical possession of the device. The wrapping key is also extractable, therefore you only need one-time offline possession of the device. The source code is horrible so I'm not going to do a full analysis but that's the gist. A recent generation phone is far, far more secure.
  - dimonomid 8y ago
    > The ATECC508A is not used correctly. It is used as a RNG and for it's crypto functions, but not for key storage. Where did you get that idea from? Preparing a device consists of the following steps: - Flash temporary configuration firmware - Send keys to the device, which are stored on ATECC508A - Flash actual u2f-zero firmware So on the second step (configuring the device), the host writes keys on the device, and those keys are stored on ATECC508A. It happens there: https://github.com/conorpp/u2f-zero/blob/master/firmware/src/atecc508a.c#L568 https://github.com/conorpp/u2f-zero/blob/master/firmware/src... I do agree that the code is bad though, but alas. I did consider reimplementing it properly, also on a more powerful chip, but I don't think I'll be able to find time for that. Anyway, dirty code doesn't mean that the device is insecure. From what I see, among other things, ATECC508A is used properly.

dokument 8y ago

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

dimonomid 8y ago
There's no easy way to increment the counter, so one would have to invent some automation for sending authentication challenges to the token and pressing the physical button every time. The time it'd take should be enough for me to get another pair or tokens, enroll it to my accounts and revoke the old one. Also let's make it not 1 000 000 but, say, 4 000 000 000, which still leaves plenty of values of a 32-bit value.
jiveturkey 8y ago
> let's say someone steals your primary U2F, can't they just increment the counter to 1000002 If they steal a primary yubikey token, no. The counter is stored and managed only in the secure element part of the device. If they steal a primary u2fzero token, which of course the proposal depends on, the counter is not protected in any meaningful way. This doesn't matter in practice, however. No site is doing anything useful with the counter.
- dimonomid 8y ago
  > No site is doing anything useful with the counter. What do you mean? In the article I mentioned that at least Google and Github refuse to authenticate if the counter is less than the last seen value. So using backup token does invalidate the primary one. > If they steal a primary yubikey token, no. The counter is stored and managed only in the secure element part of the device. If they steal a primary u2fzero token, which of course the proposal depends on, the counter is not protected in any meaningful way. Where did you get the idea that the counter on u2f-zero is not protected in any meaningful way? The counter is maintained by the ATECC508A chip and is incremented on each authentication. And also see my adjacent comment about reliably preventing primary token from returning a counter which is as large as that of backup token.

fishywang 8y ago

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

nickray 8y ago
Should? That does mean: purchasing a bunch of tokens, each of which could be lost, and registering them all. I don't think online security has normative/prescriptive rules, just tradeoffs :)

danjoc 8y ago

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.

dimonomid 8y ago
> Having a duplicate of the U2F key is a bigger problem for security than those outlined here. So, what security problems come to your mind if we consider a duplicate token buried at 1 meter somewhere in the forest (and nobody really knows where it might be) ?
- danjoc 8y ago
  My key is stolen. I have to revoke it, but I need my duplicate to log in to do it. The attacker stole my key and phone, because they were in the same place. I've only got a few minutes to go out to the remote forest and dig a meter down to find my key before the attacker uses it with the phone back at bad guy headquarters to launch the nukes. Did I bury it next to this tree or that one? Damn it, they all look the same now. Dig fast, but careful not to smash the key with the shovel. Gosh, the water table is higher than when I buried it. I hope it still works. Christ, it's all tangled in roots! Pull!! Got it! Now log in, revoke it, reflash the key, re-enroll. Phew! Humanity is saved. With PKI, I contact my spouse. Honey, can you revoke the key I'm carrying? It's been stolen. Thanks sweetie! See you tonight. I'll admit the duplicate approach makes for a much better movie. The PKI solution is positively boring. Maybe we could throw in a spouse kidnapping to keep it interesting?
  - dimonomid 8y ago
    Ah ok, I see what you mean. So can we use the PKI solution today to use as a second factor for, say, Google?
    - 8y ago

ecesena 8y ago

Incidentally I was talking to Conor about this problem yesterday. 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. 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. This means that you always need 2 distinct, active security keys anyways.

ecesena 8y ago
Assuming there's a real case where you want a backup, i.e. you fear physical damage, but don't fear lost/stolen. For consumers, I believe that the distinction between broken vs lost/stolen is very hard to explain. Think also to a company where you deploy security devices. An employee suddenly needs a backup device. Helpdesk should investigate if it was broken, or lost. It's simply a mess. For a possible solution, I think there should be a protocol where a user can export the key, encrypted for a backup device. At a high level: 1) insert the backup device and start the backup process, this export a public key, proof of possession of the corresponding private key, attestation certificate 2) insert the primary device, export the key: upon validating attestation and proof of possession, encrypts the key for the backup device and export the blob, 3) re-insert the backup device to receive the key, decrypt, store and use it. Since this moment on, the device should clearly look as a backup, for example the led could be red instead of blue (see, for example, how MetaMask displays imported keys). I don't think the protocol is really important here, I think what's really important is that: 1) the user should be the one creating the backup device, if he's knowledgeable enough and understands the risks and uses, and 2) most importantly, there shouldn't be a way to flash a security device with untrusted code. I'd be curious to hear what people think about this, would backup be useful to you? We're working on the new gen of u2fzero (https://solokeys.com https://solokeys.com), and this could be a nice feature to add if people feel it's needed.
- jiveturkey 8y ago
  There's no advantage to your method vs programming the same wrapping key into both devices. As far as the site is concerned, these are the same device but with different counter streams. I mean, yes the 2 devices can be initialized at different times, but otherwise it makes no matter.

znpy 8y ago

I'm no u2f expert (actually this article gave most of my knowledge about u2f) but imho there's a small security problem? The author says: "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." 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. This means that every server (service) stores a different value of the counter. 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? The main (compromised) token will stay perfectly usable on all the services except for those where we manually disabled the main (compromised) token. Am I correct in this?

znpy 8y ago
There should be a way to invalidate a token on all services in a single time. Maybe service providers could provide an https endpoint to perform this? It might be a good idea to give a distinct well-known name to this kind of endpoints, and provide such endpoints in the registration email so that when a token is to be invalidated, an user can regexp-search the well-known name of the endpoint in their mailbox, retrieve all such endpoints and invalidate the compromised token against all of them.
- jiveturkey 8y ago
  > Maybe service providers could provide an https endpoint to perform this? That's a good idea, with one caveat. It needs to be quite hard to revoke a token. Proof of 1-factor is not sufficient; an attacker could then simply revoke your token and then gain access. So a lost token is quite a challenge, even if there is a revoke URL. This doesn't seem automatable (to revoke all "in a single time" as you say). > provide such endpoints in the registration email In addition, the browser should record U2F interactions and know all sites on which a token was registered. Then such a list is very easily accessible, as long as the browser log is available. If it isn't, well you have email as a backup log. The fact that you can't unilaterally revoke all token registrations is the main weakness of U2F. (besides the cost and the user action required for uptake of it)

chaz6 8y ago

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.

dimonomid 8y ago
Ok cool, so whenever you register on a new service, you have to add all 4 of them, which means going to "other safe places", picking tokens, adding them, and placing them back. Also I doubt your safe places are as safe as bricking them into the wall. Apparently it's okay for you, so, keep it up then. I personally hate this. Also having 4 tokens does feel kinda too much to me. Each additional device does open a new attack vector, and if your token at home or in other places suddenly disappears, you're unlikely to even notice that quickly, while an attacker could use that time having a token. Also, if the service doesn't support having multiple tokens (as mentioned in comments, Twitter is such an example), then having 4 tokens doesn't help much.