I'm trying to figure the best strategy for having a backup U2F token. Ideally, I want to have two identical tokens; obviously I'll have the primary one easily accessible (say, on my keyring), but the second one I'd place somewhere not easily accessible (extreme cases are: bricked up into the wall, or buried somewhere in the forest). So whenever I register on a new service supporting U2F, I just use my primary token, and I know that the second one is also automatically supported. I consider this strategy a good tradeoff for being secure and still have a reliable backup option.

But apparently, with yubikeys, the only viable option is to have two distinct tokens and register both of them manually on every service I use them for. However, this is less than ideal because I'd have to keep both of them easily accessible: it's okay if I have to unbrick the backup token in a bad event of losing the primary one, but doing that for every new service is not viable.

Actually, I was surprised to find out that even though yubikeys do support programming of OTP key material (and they even have two slots, it's really nice), they do not support programming of the secret key used for U2F.

Is there any particular reason that U2F secret key on yubikeys is not programmable, even though secret data for other modes (e.g. OTP) is programmable?

  • your second question was off-topic for this site – schroeder Jul 27 '18 at 16:50
  • Schroeder is right, the question of yubikeys not being programmable is off-topic, but if I had to speculate, it would be A) to prevent users from locking themselves out by overwriting their secret key and B) to prevent attackers from overwriting the original secret key with a known value before you receive it. – Mr. Llama Jul 27 '18 at 17:21
  • @Mr.Llama Actually that's the part that's on-topic :P The off-topic part was a product recommendation request. – AndrolGenhald Jul 27 '18 at 20:01
  • I am wondering why so many people want to have a clone of their security device. Having a clone does neither increase security nor usability. I recently LOST my yubikey! If I had a clone, there would be no use in having a clone. The yubikey I LOST is COMPROMIZED, so I have to revoke or delete this device from the backend systems or services. At the same moment the clone would be compromized. And if I revoke the original key, the clone would be revoked, too and rendered useless. – cornelinux Jul 28 '18 at 9:07
  • @cornelinux It's all about tradeoffs. In theory, yes, the lost yubikey could be taken advantage of by someone. But, considering that, I still believe that at least personally for me, it's negligeably unlikely that anyone on earth would actually be able to make use of it (in a short period of time they have until I get a new token, login to my accounts using the backup, add a new one and revoke the old one). An U2F token is just one factor; I use keepassx to keep my passwords very strong, so they would also have to get access to that. Not saying it's impossible, but, again, negligeably unlikely – Dmitry Frank Jul 28 '18 at 9:19

So while reading the U2F overview I realized that what I want is impossible with the way U2F is designed, because device has a counter which is incremented on every authentication (see section 8.1 of the overview linked above)

So it's not about yubikey in particular, it's about the whole U2F. That's sad to me, I really liked the idea of having a clone which is hard to access even for me. Not being able to use that strategy means that we have to come up with other recovery methods, which will be different for every service (e.g. not every service supports adding multiple U2F tokens), and overall it's anyway less secure than two devices programmed with the same secrets.


UPD: actually, I've got an idea. There is an open-source project u2f-zero. So the plan is: get two devices, program them with the same secrets, BUT the backup device should be programmed with a small modification: instead of returning a plain counter from the cryptochip (u2f-zero uses ATECC508A), return something like counter+500000. I'm unlikely to exceed 500000 authentications during the whole life, and it's still a small fraction of the whole counter range anyway (which is 32-bit).

So, if I'm unlucky enough to lose my primary token, I go to the forest, dig out the backup token, and it should work for all of my services right away. There is even one nice side effect: after I use the backup token first time, the primary one will be immediately invalidated because its counter is lower.

UPD2: I wrote a detailed article about it: Reliable, Secure and Universal Backup for U2F Token

  • I kind of like downloadable recovery codes for this, as GitHub, Google, and a number of other providers use. You can print them out and keep them locked up, and it’s way less expensive as a backup solution. – nbering Jul 27 '18 at 23:03
  • Recovery codes have the same problem that I need to generate them for every service separately, so I have to keep them somewhere accessible (likely in my apartment). Burying them in the forest is not an option. As to the cost, well, $20 for a convenient universal backup is not much. – Dmitry Frank Jul 27 '18 at 23:30
  • 1
    Maybe it’s nuance, but I disagree with it being the same problem as the flow is one way. You don’t need to dig out all your other recovery codes to sign up for a new service. You can download and print them off, storing them in your safe place at your convenience. Whereas signing up with a service and using your backup key requires you to retrieve the key. – nbering Jul 27 '18 at 23:34
  • That's true that I don't need to dig out existing keys to generate new ones, but I don't want to spread those codes around. I'd like to keep them in a single and quite safe place. – Dmitry Frank Jul 28 '18 at 0:23
  • Actually, I think I've got an idea how to implement the desired strategy. I updated my answer, if you're interested. – Dmitry Frank Jul 28 '18 at 0:33

Have you looked into how devices like the Trezor implement U2F? The device backs up all keys using a 12 or 24 word seed phrase, so they are easy to clone without keys ever touching a computer. The U2F counter is also restored when recovering using the seed phrase. Apparently they use the unix timestamp as the counter when restoring ensuring that it is always larger. Of course this means you can only have 1 device working at a time, but if the first is lost / damaged, the second will have the correct counter after being restored.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.