3 ms·

I'm not sure if you've read the article. > If the primary is lost or stolen, the key should be invalidated Exactly. > and thus the backup device is useless.

I'm not sure if you've read the article. > If the primary is lost or stolen, the key should be invalidated Exactly. > and thus the backup device is useless. The article mentions multiple times that the backup is set up in such a way so that right after we use the backup token on some service, the primary token becomes immediately invalidated for this service. Read the article for the details on how it's implemented.

ecesena 8y ago
An attacker in possession of the primary device can increment the counter, making the primary still working, and invalidating the backup. In crypto, keys are secrets, the rest can’t be relied on for security. Edit: grammar
- dimonomid 8y ago
  > 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

An attacker in possession of the primary device can increment the counter, making the primary still working, and invalidating the backup. In crypto, keys are secrets, the rest can’t be relied on for security. Edit: grammar

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