Generating and securely storing MFA/2FA recovery tokens

Question

I'm trying to implement 2FA on my site, and cannot figure out how to generate and then securely store recovery tokens.

From what I've seen, if for whatever reason you cannot MFA (lost your device maybe) you can use a recovery token as your second factor. I am concerned about storing them securely. On sites like Github you can go and view your recovery tokens at any time, which means they are not hashed and stored. This does not seem very secure. And my google-fu seems to have abandoned me when searching for guidelines and best practices on this.

PS - I'm looking for guidelines on how to implement generation and storage of recovery tokens as a service.

Answer 1

The backup keys essentially become equivalent to your password. The guidelines you are looking for are the same guidelines for storing your personal passwords. There won't be different guidelines.

The one slight difference between passwords and MFA codes is that you tend to need those codes very infrequently (maybe only ever once), and when something has gone wrong. That means that you need to follow the password management guidelines for "disaster recovery" or "business continuity" in business.

That usually means printing/writing them out and storing the physical media safely (locked, sealed, somehow obfuscated in case someone stumbles onto them) and in a way that you can access it when things have gone wrong. The details of this approach highly depend on the scope of "what can go wrong". Personally, I go with the earthquake/flood scenario where I lose my device and desktop and need to log into a new/strange device.

Answer 2

The other answer is correct that recovery codes should be hashed. The NIST published guidance on this in 800-63b section 5.1.2, Look-Up Secrets, stating as much:

... A common application of look-up secrets is the use of "recovery keys" stored by the subscriber for use in the event another authenticator is lost or malfunctions. ...

Verifiers SHALL store look-up secrets in a form that is resistant to offline attacks. Look-up secrets having at least 112 bits of entropy SHALL be hashed with an approved one-way function as described in Section 5.1.1.2. Look-up secrets with fewer than 112 bits of entropy SHALL be salted and hashed using a suitable one-way key derivation function, also described in Section 5.1.1.2. The salt value SHALL be at least 32 in bits in length and arbitrarily chosen so as to minimize salt value collisions among stored hashes. Both the salt value and the resulting hash SHALL be stored for each look-up secret.

For look-up secrets that have less than 64 bits of entropy, the verifier SHALL implement a rate-limiting mechanism that effectively limits the number of failed authentication attempts that can be made on the subscriber’s account as described in Section 5.2.2.

Despite this, some prominent sites (including GitHub, Google and Facebook) store them in plaintext or reversibly encrypted, allowing users to view them at any time.