1

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.

schroeder
  • 123,438
  • 55
  • 284
  • 319
Violet McKinney
  • 13
  • 4
  • Why are you storing them? And perhaps, how are you generating them? – schroeder Jan 02 '20 at 09: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 McKinney Jan 02 '20 at 09: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 02 '20 at 09: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 02 '20 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 McKinney Jan 02 '20 at 10:02

1 Answers1

1

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.

schroeder
  • 123,438
  • 55
  • 284
  • 319
  • 1
    So yes, I should hash them at the same level I do with passwords? (bcrypt) – Violet McKinney Jan 02 '20 at 10:12
  • Or better yet, use a better library with this function built-in. – schroeder Jan 02 '20 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 McKinney Jan 02 '20 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 02 '20 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 02 '20 at 10:59