In TOTP implementations, it's always suggested that you give your users recovery codes. Should I treat these like tokens? Display them once and hash them?

If so, I'd love to know why. If not, I'm curious too.

  • Why are you storing them? And perhaps, how are you generating them? – schroeder Jan 2 at 9:42
  • @schroeder I am generating the recovery codes through the github.com/pquerna/otp TOTP library. I'm storing them in the database so that the users can use the recovery codes?? I don't understand the question. – Violet Jan 2 at 9:49
  • With this library, this is what they do: "These can simply be randomly generated strings that you store in your backend." There are TOTP implementations that do not pre-generate recovery codes and do not require you to store anything. – schroeder Jan 2 at 9:58
  • In fact, it looks like this library does not create recovery codes at all. It looks like you have to create that logic and function yourself? – schroeder Jan 2 at 10:02
  • "that you store in your backend" "do not require you to store anything" These are conflicting statements. I am the backend. I am the TOTP server. The logic for creating the codes is entirely irrelevant. I am asking about whether I should hash them. It seems not according to the docs. – Violet Jan 2 at 10:02

What it appears you have in this particular TOTP library is the requirement to create and implement a 2FA bypass function outside of TOTP.

These are a set of one time use codes that can be used instead of the TOTP. These can simply be randomly generated strings that you store in your backend.

Those recovery keys are "golden keys" that unlock the account. These become like a second password, and as such, should be protected and implemented in the same manner.

|improve this answer|||||
  • 1
    So yes, I should hash them at the same level I do with passwords? (bcrypt) – Violet Jan 2 at 10:12
  • Or better yet, use a better library with this function built-in. – schroeder Jan 2 at 10:13
  • This is the major OTP library. I think I can trust myself enough to hash and salt passwords correctly. Thanks for the answer. – Violet Jan 2 at 10:16
  • "should be protected and implemented in the same manner" the problem is probably that you can hash passwords because you do not need to know them. but you need (afaik) the original unhashed totp-codes to verify the userinput on a login. so you can not treat totp like a password. – anion Jan 2 at 10:41
  • @anion that's not how this library works. Recovery Codes: "These can simply be randomly generated strings that you store in your backend." – schroeder Jan 2 at 10:59

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.