Does the existence of two-factor recovery codes mean that my 2-factor code isn't completely random?

Question

With some services that use standard 6-digit TOTP codes, they also offer the ability to have a set of backup codes, in case you lose your two factor device.

With Google, for example, you can print out a hardcopy of 10 backup codes. These are more than 6 digits, so that isn't worrying.

However, some other sites that generate backup codes do use 6 digits. Reddit, for example, is rolling out two factor authentication, and their 10 recovery codes are all 6 digits, which is the same length as a standard two-factor code they use.

Does this mean that those 10 codes are somehow never going to be generated at random by the TOTP seed key? Since they're using a standard algorithm (used by Google Authenticator, Authy, etc), I assume every 6 digit number is possible.

Alternatively, does that mean that over time, some of these codes will become invalid, assuming the TOTP algorithm generates that code? Or even longer term, if I log in many times, I imagine I'll run across one of these codes eventually, use it to login, and unknowingly remove that code from my backup list.

What can be implied about a setup where the two-factor recovery codes are the same number of digits as a standard two-factor code?

Answer 1

The backup codes, or scratch codes, are totally independent (at least in terms of operation) from your standard codes. TOTP is based on the time. The scratch codes are rather based on an incremental counter.

The implementation details are probably provider dependent, but I think it's safe to assume that they use 2 different seeds. Maybe the underlying HMAC function changes as well, it's hard to tell.

On the number of digit, it all comes down to the choice of underlying HMAC and/or Truncation function. Why would the scratch code being longer than TOTP could be to ensure a sufficient level of security. The scratch code being fixed for potentially a long period, it makes sense for them to be longer. TOTP on the other hand requires less, because cracking the shorter code in the given time frame of availability is already hard enough, hence it provides additional flexibility to the user who has to type it manually.

Answer 2

There are two ways to implement recovery codes

• derive them from the TOTP seed. Then the seed works like a password for the recover codes while it is used as seed for the login codes.
• create some random recovery codes and store them independent from the TOTP seed. Then allow to use them just like a password. Possibly removing them from the recovery code database after the user used them.

Answer 3

First of all, like M'vy pointed out, the implementation is totally provider dependent.

What can be implied about a setup where the two-factor recovery codes are the same number of digits as a standard two-factor code?

I think you can imply that such a service is more insecure! If a recovery code is a 6 digit number, the service is more insecure:

See this: The 6 digit TOTP value is only valid for 30 secs or 60secs including a time window according to RFC6238.

The 6 digit RECOVERY code is valid like.... forever. So depending on the implementation and recovery workflow, an attacker could simply "try" all 1 Mio codes of a recovery code. In contrast to TOTP, where the attacker only has 60secs to try all combinations, an attacker has several years to try all recovery code combinations.