5 ms·

> An attacker in possession of the primary device can increment the counter, making the primary still working In the article I explain how to make it impossibl

> An attacker in possession of the primary device can increment the counter, making the primary still working In the article I explain how to make it impossible to just "increment the counter" of the primary token, see this section: https://dmitryfrank.com/articles/backup_u2f_token#caveat_with_the_counter https://dmitryfrank.com/articles/backup_u2f_token#caveat_wit... > In crypto, keys are secrets, the rest can’t be relied on for security. First, there's no 100% security in the world: it's all about time and resources, and a proper security consists of many layers. The counter is one of them; after all, it does exist in U2F protocol for a reason (to prevent clones). And if you've read an article, you'd notice that it mentions: the backup token should only be used to log into accounts, add a new key, and invalidate the old one. Of course it would be a bad idea to keep using backup token. To avoid waiting for the new pair of tokens to arrive, I keep them together with my backup: my backup consists of the backup token itself, and also a brand new pair of tokens (new primary and new backup), which aren't used anywhere yet. So if something terrible happens and I lose my primary token, I go all the way down to get the backup, use the backup token to login to each service, add a new primary token, and revoke the old one.

ecesena 8y ago
I don't think we understand each other. If a device gets in the hands of the attacker, I won't assume he/she's going to use your code and obey to your restrictions. The primary device contains the key, that the attacker can possibly extract and use, setting any arbitrary counter he/she wants. I see your point on the limited usage of the backup while you buy a new device. This goes back to my initial comment... you basically always need 2 active security devices, so I don't really see any big benefit in having a backup vs a secondary device.
- dimonomid 8y ago
  > The primary device contains the key, that the attacker can possibly extract and use, setting any arbitrary counter he/she wants. Again, not saying it's impossible, but with the existing implementation, it takes considerable amount of time. I should be able to get the backup token faster. > I don't really see any big benefit in having a backup vs a secondary device. A big benefit for me is not having to add my backup token to every single service. It's both more convenient and more reliable (since I can't forget), and also more secure, because I can take my backup token and brick it into the wall. If this benefit is not a benefit for you, then, fine, we're not going to agree.
  - ecesena 8y ago
    Got it, this makes sense to me. And sorry, I was rereading the thread, I don't want to think I'm dismissing your whole article, I really appreciate you writing about it. I think the time is a big advantage. As I mentioned, I'm working with Conor on the FIDO2 security key (actually, update [1]), and we were thinking to an option to create backups, maybe for advanced users. I'll keep you posted if we end up doing something in the space. [1] https://news.ycombinator.com/item?id=17777224 https://news.ycombinator.com/item?id=17777224
    - dimonomid 8y ago
      Thanks! Yeah Conor mentioned that to me; I think the real benefit (at least personally for me) would be not being able to buy pre-made matching pairs of tokens, but being able to easily write my own key material plus the counter boost value. You know, yubikeys do have this functionality for OTP: their utility allows to program OTP keys. I actually expected the same for u2f, but alas.

ecesena 8y ago

I don't think we understand each other. If a device gets in the hands of the attacker, I won't assume he/she's going to use your code and obey to your restrictions. The primary device contains the key, that the attacker can possibly extract and use, setting any arbitrary counter he/she wants. I see your point on the limited usage of the backup while you buy a new device. This goes back to my initial comment... you basically always need 2 active security devices, so I don't really see any big benefit in having a backup vs a secondary device.

dimonomid 8y ago
> The primary device contains the key, that the attacker can possibly extract and use, setting any arbitrary counter he/she wants. Again, not saying it's impossible, but with the existing implementation, it takes considerable amount of time. I should be able to get the backup token faster. > I don't really see any big benefit in having a backup vs a secondary device. A big benefit for me is not having to add my backup token to every single service. It's both more convenient and more reliable (since I can't forget), and also more secure, because I can take my backup token and brick it into the wall. If this benefit is not a benefit for you, then, fine, we're not going to agree.
- ecesena 8y ago
  Got it, this makes sense to me. And sorry, I was rereading the thread, I don't want to think I'm dismissing your whole article, I really appreciate you writing about it. I think the time is a big advantage. As I mentioned, I'm working with Conor on the FIDO2 security key (actually, update [1]), and we were thinking to an option to create backups, maybe for advanced users. I'll keep you posted if we end up doing something in the space. [1] https://news.ycombinator.com/item?id=17777224 https://news.ycombinator.com/item?id=17777224
  - dimonomid 8y ago
    Thanks! Yeah Conor mentioned that to me; I think the real benefit (at least personally for me) would be not being able to buy pre-made matching pairs of tokens, but being able to easily write my own key material plus the counter boost value. You know, yubikeys do have this functionality for OTP: their utility allows to program OTP keys. I actually expected the same for u2f, but alas.