Although using multi-factor authentication is clearly a good move, I'm struggling with the 'one-time recovery codes' concept. It seems to me that if you choose to use them, what you're doing is putting extra security on the front door (like bolts and padlocks) making it harder to break in that way, but installing a paper-thin back door at the same time!

These 'one-time recovery codes':

  • act like master keys, but as they're just a few digits they aren't 'strong' passwords
  • must be stored 'provider' side, so you're vulnerable if the provider's systems are compromised
  • have to be stored locally in some fashion(1), introducing another vulnerability

(1) I see there are several threads on StackExchange that already discuss this point.

Isn't the best course of action to disable 'one-time recovery codes' entirely? (Assuming that the provider's system actually allows you to do so once they've been set up....).

  • 6
    If you don't trust the provider side why are you there? The provider side can store it with HMAC.
    – kelalaka
    Dec 9, 2020 at 19:25
  • 1
    I'm not sure how the provider protects them, but from the user side, I've heard this asked several times, and in each case the question's seemed to assume the codes would be stored insecurely. The correct way for a user to store these codes is something equivalent to "printed on paper and stored in a safe" -- i.e., not online in any way, and even physically, not trivially accessible to just anyone who happens to be nearby. Yes they are insecure, but they have a purpose to we compensate by taking extra care storing them.
    – user88917
    Dec 10, 2020 at 4:45
  • @kelalaka a) there's no way for the user to know whether the codes stored by the provider are protected with any encryption at all and b) if the provider's systems are compromised, a ten-digit code is ludicrously weak.
    – Pendantry
    Dec 10, 2020 at 15:53
  • You know that the recovery codes can only be used to bypass the 2FA and not the main password, right? You need to know the password in order to use the recovery code.
    – eesiraed
    Dec 11, 2020 at 0:58
  • @Pendantry I'll repeat kelalaka's question: if you don't trust the provider to store the recovery key properly, why do you trust them in any other way? Why are you so worried about the recovery key when they could have left their database open to the internet with system/system as superuser credentials? If you don't trust them to be competent enough to store a key, you shouldn't be giving them your data at all.
    – Demonblack
    Dec 11, 2020 at 12:36

7 Answers 7


tl/dr: One time recovery codes give account owners an option for regaining lost access. People who consider this an additional risk can always ignore it or destroy it, but people who are worried about losing access to critical services can certainly come up with a secure way to store it. As a result, it's a good option to have for services that may be critical to businesses and/or people.

There is no secure

In most of the systems I've seen that have one time recovery codes, they are an optional feature. As a result, they give the account owner a way to mitigate competing risks.

When it comes to security, it's always important to remember that there is no such thing as "secure", only "secure enough for me". Different companies and people have different risk tolerances, different threat models, and different concerns.

Mitigating denial of service vulnerabilities

From that perspective a one time recovery code is a mitigation against a very particular kind of denial of service vulnerability: faulty (human) memory. In some services, if you lose your password, you are effectively locked out of your account permanently. In some cases you may fix this by getting a new account and suffering the inconvenience of having to set it up again. In some cases this may destroy your business. If a particular account falls in the latter category then you probably don't want to risk forgetting the password and losing access.

One time recovery codes are obviously designed to address that (and other kinds of events that may cause you to lose access). You may decide that printing a one time recovery code on a piece of paper and putting it in (for instance) a bank safety deposit box is a good way to mitigate the risk of lost account access without increasing the risk of account theft.

Then again, you may decide that you aren't worried about losing account access and so you may "print" the one time recovery code from the site and then immediately throw it away/burn it/never actually write it down/never actually request it in the first place. After all, if you don't have it, then you don't have to worry about accidentally leaking it. In this case, you are deciding that the increased risk of account theft via the recovery code is not worth having an alternate means of access.

From the service provider perspective

The whole point is that you get to decide whether or not you wish to make use of this feature. Many sites I have seen it make it optional, but even if it isn't, you can destroy it easily enough. However, as a service provider, if I provide the kind of service that may be critical to running a business, then I probably have some customers who want to have an alternate means of access in the event of account lock-out. As a result, it makes perfect sense for me to provide this as an option.

Certainly, this will save me a lot of trouble when I start getting frantic emails from people who claim to have lost access to their account. Telling the difference between "I lost access to my account" and "I'm trying to use social engineering to convince support staff to give me access to someone else's account" can be surprisingly tricky. If I build options that give my customers the self-service options to recover their own account, then that gives me less support requests to handle and also decreases my legal liability (since if I accidentally give away an account to an attacker I will definitely be held liable for it).

Moreover, since these are features that will be used rarely, the provider can make extra protections around it. You would certainly put in protections against people trying to brute force recovery codes, although I don't think that is a real concern anyway. Every recovery code I have seen are long and random enough that they would be immune from brute force anyway. In general though, the concept itself is perfectly valid. Whether or not a particular provider may have implemented an insecure implementation of one time recovery codes is another matter.

Finally, adding recovery codes doesn't make it easier for a provider to access your data. The provider can already do that anyway, and will do that if requested by law enforcement regardless of whether or not you have a recovery code. In the case of services that are designed so that the provider cannot access your data (for example a password manager), then they would have designed the recovery codes so that they are also inaccessible to the provider. As a result, recovery codes do not generally create an additional risk vector for internal attackers.

  • 4
    You make some valid points. However, you say "Every recovery code I have seen are long and random enough that they would be immune from brute force anyway." That's not my experience; all the codes I've seen so far have fewer than ten digits! Also, citing Facebook as an example, having set up the codes, I don't see any way of deleting them. I think my main concerns are the possibilities of the proverbial 'disgruntled employee' (at the provider's side), and the idea of providers being obliged by law to divulge any such codes to gain access to the account data.
    – Pendantry
    Dec 9, 2020 at 11:53
  • 5
    @Pedantry if a disgruntled employee wanted to gain access to an account I doubt they would need your recovery code to do it. Same with law enforcement - if they subpoena a provider for your information then law enforcement will get your information, and won't need your recovery code to do it. This is not adding an additional threat vector internally Dec 9, 2020 at 13:08
  • 13
    @Pendantry, ten digits is plenty if you're restricted to three recovery attempts per day.
    – Mark
    Dec 9, 2020 at 22:33
  • 2
    @user253751 that assumes that the brute force limit on account recovery is per-IP instead of per-account. Obviously for user logins you want brute forcing protection to be based on IP instead of account, but account recovery is a very different process so the protections are going to be different too. I'm not saying that per-account protection is the way to go either, I'm just saying that the protections are likely very different than "the usual". Presumably every business has their own approach to this, especially since account recovery is such a sensitive action. Dec 10, 2020 at 15:40
  • 13
    @user253751 for starters, the recovery code is for bypassing 2FA only, which is verified after a successful "normal" login - you'd still need the actual user's password, and then you get 3 tries to guess the recovery code for that particular account So you'd need to know the passwords for 333,334 user accounts to get into one of them.
    – Peteris
    Dec 10, 2020 at 19:36

Password recovery has always been a security weakness because the goal is to allow to make an action on a account without knowing the password. In controlled systems you had to go to the admin desk, tell him that you lost the password and let him shout that you were a stupid boy/girl. In the end, after confirming that you actually had a legitimate access, the admin (a real human being) had to manually reset the password.

This was seen as secure because the admin had clearly identified and authenticated that the request was coming from the legitimate user.

But on large sites or applications, users self register, and having human beings in charge to identify the users and make sure that a password reset request actually come from a legitimate user is simply not feasible. So site owners had to find a way to let users recover their account if they forgot the password.

The most common way is to send a time limited token via mail. If the user registered that recovery e-mail address, they are supposed to own it, and be accountable for its security. Unfortunately, it cannot be used for the main mail account (unless the user has a secure secondary account).

The worst way is the secret questions. Because someone knowing the user can guess the answers. Or can guess after searching on social networks. And spelling problems can arise (did I use NEW YORK, NEW-YORK, New York or New-York?). This is known to have allowed account steal from public persons (Sarah Palin, for example).

So site owners ended with one-time recovery passwords. It is indeed a poor solution that lowers the security level of an account. But it may not be the worst way. And telling your users (which are your clients, meaning the ones that allow you to earn money) that if they are stupid enough to forget their password, then you do not want them as clients, is probably not the best way to develop your business...


No, this is not a back door

A back door, in computer security, refers to a builtin mechanism for

  1. individuals who are authorized to access the system to continue to access the system after they are no longer authorized
  2. individuals who are not authorized to access the system but have some level of indirect control over the system (like, they wrote the code) to access the system

The scenario you talk about is an alternate authenticator, not a back door.

but is it secure? maybe

Your question (and many of the comments) are focused on "but can it be brute forced?" Well... that's complicated.

An online brute force attack requires some number of attempts to succeed. Those attempts have to occur fast enough it's realistic. For example, in a system that requires 1000 attempts to succeed but only allows one authentication per year, and the protected resource isn't going to be of any value after 100 years, the resource is sufficiently safe.

When you do your calculations - and you HAVE to do calculations - you have to evaluate the whole system.

  1. what is the value of the protected data?
  2. will the value of the protected data expire at some time in the future?
  3. if the oracle - the thing against which you test whether you have the right password or not - is a live server (or service), how quickly will it allow you to perform the attack?
  4. if there are multiple users who have access to the system, how many of them have recovery passwords? How many recovery passwords need to exist in order to succeed fast enough to get to the data while it's still valuable?
  5. are there any other compensating controls? Like other (chained) authentications required during the recovery attempt, NOCC alerts with mandatory investigations? Other authenticators (other factors) required for this authentication? Very short lifetime of the session before somehow otherwise validating the account? restricted "recovery access" that doesn't give you full access to all data? highly restricted timeframe during which the "recovery" actions can be used with the recovery password (you didn't specify if this is account recovery or logging into a specific damaged server, or something else)?

you have a few assumptions that aren't true in all situations

act like master keys,

No, they act like passwords.

but as they're just a few digits they aren't 'strong' passwords

You assume that a specific strength is needed, but the strength depends upon a LOT, as described above.

must be stored 'provider' side, so you're vulnerable if the provider's systems are compromised have to be stored locally in some fashion(1), introducing another vulnerability

All authentication mechanisms require that the provider store something. Passwords require hashes. Hash chains require the previous hash in the chain. Certificates require CA certs. Private keys require public keys.

Why do you think that this must be stored in such a way that it's completely hosed if leaked? Why do you think that it can't be stored in the same manner as another mechanism? What makes you think that the authentication protocol is exactly that of a password rather than some form of cryptographically secure challenge-response?


They do introduce a backdoor, but that's the whole point. How else is someone supposed to regain access to their account if the device they're using for 2FA fails? By contacting the account provider and asking nicely? We tried that and scammers love it.

Recovery codes are the only practical solution to this problem. The only way to have perfect security is with a perfect system where hardware doesn't fail, and that's obviously impossible.

There's no reason to be overly concerned with these codes, anyway. The only way they can be a security risk is if the user leaks them (which is the user's problem) or if an attacker gains direct access to a security provider's core systems, in which case recovery codes leaking are the least of that provider's problems.

  • As I mentioned already, there are questions on this forum that address the local storage issue. I think my own main concern is, as you say, "if an attacker gains direct access to a security provider's core systems." Provider systems are breached all the time (as a quick visit to haveibeenpwned.com will attest): for all the user knows these low-quality codes could be stored in plain text on those systems.
    – Pendantry
    Dec 10, 2020 at 15:42
  • @Pendantry If they are willing to store these codes as plain-text you should be more worried that they probably have the passwords as plain-text too. Dec 10, 2020 at 15:58
  • @fəˈnɛtɪk you're missing the point that I as a user have the ability to employ very high strength passwords. All the 'recovery codes' I've seen are very low quality short digit codes.
    – Pendantry
    Dec 10, 2020 at 19:26
  • 2
    @Pendantry You just stated what you were actually concerned about was the improper storage of these passwords. If they are being improperly stored the strength of the password doesn't matter. Dec 10, 2020 at 19:45
  • @fəˈnɛtɪk Uh... it does matter. Presented with a database of codes, some of which are low quality and others are, say, 50 characters long such as '÷µ¼ªÜï#ãÜ"êüJeJùÁZùgJØTÛ»ìUh÷·(ÅJ¶að^«ùð ÿTÆhì6^', which ones would you look at first?
    – Pendantry
    Dec 11, 2020 at 17:32

The one-time passwords might be "weak" based on their limited length. But they are in principle slightly more secure than a password of the same length. Why? Because it's highly unlikely that you use the one-time password on another website. If someone gets the database of passwords from another site and you reused your password then the attackers can break into your account. However, as long as you did not use a one-time password from a site as a password on another then the attackers would be limited to brute force guessing the password by trying to log into the website. Hopefully, a competent website would block people trying a few thousand logins with a wrong password.

As pointed out by others, it's part of how much security do you need? I'm much more worried that I've reused a password somewhere (stupid websites that don't let me use password managers or otherwise make me use weak passwords) and that gets leaked than someone breaking into my house and finding a random piece of paper with some numbers on it and knowing that is the one-time recovery key for a website.


I see a couple of related points here that haven't been addressed:

  1. One-time master password complexity (weak - all numeric and short)
  2. Brute force / lockout attempts on 2FA.

For 1) The weakness in length of these master 2FA codes, I agree, is a weakness. Especially if they are generated using a weak or known IV (initialization vector), or that gets leaked, it's possible to guess, or narrow down, valid codes. For an example, see old BIOS unlock utility, that took an input and generated 6-8 short codes to unlock a BIOS.

For 2) On one of my 2FA sites I use, if I mistype or time out the TOTP code, I have to re-enter the password as well. If I mistype it 2x I get a delay. For other 2FA sites, I don't know if they lock attempts after 3 attempts or something similar.


The key thing is that the one time password can't be used to guess your real password by brute force offline. Presumably, the online password validator would shut a guesser off after a few tries. If your password recovery OTP (or some other mechanism) is intercepted, you're fucked anyway.

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.