7

I've been trying to implement 2FA for a web application, both server and client side. As everybody knows, an H/TOTP is intended to prove that I own something, for example through the use of an authenticator app installed on a mobile phone which will generate the OTP for me.

I'm not sure about what that "something" I own is, so my first question is: is this "something" my phone, or is it the salt for the OTP generation which I load into the app installed on my phone? (If it is the salt, does owning not equate knowing, be it somewhat complicated with an algorithm between me and the salt?)

Given the risk that I loose access to my mobile phone on which I have installed the app, many sites offer me to download backup codes. These codes should be stored in a password manager, just like the password from the first factor. Generally it is possible, after entering my username and password, to bypass the OTP process and enter a backup code through an alternative flow.

My second question is: is my assertion correct that this way the second factor is reduced to something I know, a backup code, and thus merely extending the first factor? (And thus rendering the whole 2FA almost useless, only increasing security a little by adding a second thing I need to know, while increasing the inconvenience of managing more passwords.)

scola
  • 71
  • 2

3 Answers3

7

Does the existence of a recovery code render 2FA useless?

No, for several reasons.

First of all, using a recovery code is very noisy. Using a recovery code is not identical to using a password with a TOTP, so a recovery code should not be seen as "simply an extension of the first factor". So if an attacker would use a recovery code and change your phone number to one that the attacker controls, you can be sure that you would get various notices (e.g. via e-Mail, app notification, etc.). Also if you would contact support immediately, stating that an attacker cracked your recovery code, you would probably have high chances of having your access restored.

Secondly, it's recommended not to store a recovery code in the same location as your passwords. Storing your passwords in a Keepass database is a good idea. Recovery codes, however, should not be stored there. I would recommend writing them on a sheet of paper and sticking it in a folder with other important documents (preferably in a safe, or similar). This way, an attacker that gains access to your Keepass database and is able to crack the password of that database, doesn't have access to both password and recovery code.

That way, in order to steal your recovery code, an attacker would either have to guess it (which should be impossible with a recovery code like Lining Everybody Frays Overpay Swinger Boogeyman Rise Anvil Pastel Quaking), or gain access to your home (at which point the security of your GitHub account is probably secondary).

  • If I present my backup/recovery code (which was provided to me by the application) all I prove is that I "know" a backup code that is also in the application database linked to my account. I doesn't prove anything about me "having" something, which is what the second factor is all about. – scola Nov 08 '19 at 12:25
  • That is also not the purpose of a backup code. A backup code isn't "my phone isn't at hand, just use this code instead" - it's "I lost access to my second factor. Here is the backup code to prove it's really me. Please do something!". The point is that a password plus a backup code is *not* identical to a password and a token from a second factor. –  Nov 08 '19 at 12:27
  • This is the process as I have found it implemented in several sites: 1. Enter username/password. 2a. Enter TOTP or (if you lost access to the second factor) 2b. Enter backup codes. In the case of 1 + 2b (which is and always will have to be accessible for every user) the login process has been reduced to 2 things I know: my password and a backup code. So indeed, password + backup is not identical to password + token, and that is exactly the problem. – scola Nov 08 '19 at 12:49
  • 1
    If a website treats login with a recovery code identical to login with a regular second factor, then *that* is the actual problem. A recovery code being used should always be treated as an exceptional case, not as regular. –  Nov 08 '19 at 12:51
  • But it is exactly the way how e.g. Github works. If I enable 2FA in Github, then, when I login with my username and password, I am requested to enter the TOTP _or_ go to a seperate page where I can enter a backup code. This is necessary, because if I had lost my authenticator app, I would be locked out forever, if there would be no possiblity bypass it and go to the backup code page immediately after I had entered my username/password. So, username/password + backup code is a necessary flow, but it is the weakest link in the defence mechanism, and thus reduces 2FA to 1FA – scola Nov 13 '19 at 10:41
  • @scola In this case, I urge you to contact GitHub's security team and report the bug. –  Nov 13 '19 at 10:48
  • I salute your agreement, and your concern, but the problem is that at least Google and DigitalOcean have implemented it in the same fashion (because, as I have pointed out above, preventing permanent lock out can hardly be achieved in any other convenient way). I cannot believe that these respected companies have overlooked this problem in implementing their security policy, so I will wait a little longer for someone to point out my misunderstanding of the case - at the level of principle of course, since security is always at odds with convenience in one way or another. – scola Nov 13 '19 at 14:24
0

You should not store both the passwords and your backup codes in your password manager due to the problem your describing. I would propose you store it separated. For example a USB drive in a safe or a sheet of paper stored within your personal documents would be a better place for your recovery codes. Then an attacker needs to have access to your home as well.

LittleBobbyTable
  • 3
  • 2
  • Writing down the backup codes or putting them on a USB drive, doesn't change the nature of the codes. Otherwise, writing down the password would change the password into something I 'have', too. – scola Nov 08 '19 at 12:27
  • Thank you for pointing this out, your correct. My point was more that it is still useful and I will try to change the answer accordingly. – LittleBobbyTable Nov 08 '19 at 13:57
0

A backup code is a recovery mechanism, and I second what MechMK1 said about not storing them in the same place as the passwords. I also have them printed and stored with various "important" papers in a drawer at home.

As such, the way it is used, the way it is meant to be stored long-term, even if the website does not offer guidance (which it should, ideally, but many don't), means that you cannot look at it only from the "something I know [etc]" point of view. It's beyond that.

  • Why is it _beyond that_. The second factor in 2FA is about proving that you own something. A printed backup code is nothing something you own, as I have pointed out in https://security.stackexchange.com/a/220785/221167. – scola Nov 13 '19 at 10:44
  • We're arguing semantics here. If you want to say "backup codes are not 2FA" that's fine; the fact is they're a *recovery* mechanism, while 2FA is for day-to-day use. And because they are so "powerful" yet not 2FA, they need to be protected correspondingly well -- such as keeping only a printed copy in a safe. –  Nov 13 '19 at 22:23
  • But as a recovery mechanism, necessarily always accessible after you entered username/password as a bypass around 2FA, because otherwise a loss of your TOTP generator would lock you out forever, backup codes reduce the defense mechanism to 1FA. The defense is as strong as its weakest part, which is the backup code in this case. – scola Nov 14 '19 at 07:06
  • A backup code is **not** weak if you store it properly. That's the whole point of printing it and keeping it in a safe. I guess you have a different definition of "weak". To each his own.. –  Nov 14 '19 at 11:08
  • The strength of a security credential/token is an intrinsic quality of the credential/token itself (its unpredictability by virtue of e.g. its randomness), and is not determined by its storage. (Storing "abcd" properly doesn't make it a strong password.) But I should have said: the _recovery mechanism_ based on backup codes is the weakest part, because it becomes possible to gain access to the system through presenting two things you know, the username/password and the backup code, and no longer one thing you know and one thing you have (which is prerequisite for a proper 2FA implementation). – scola Nov 14 '19 at 12:39
  • "it becomes possible to gain access to the system through presenting two things you know, the username/password and the backup code". I grow tired of this "debate". I'll just say that the backup codes for my github and gmail etc certainly do not fit any definition of weakness in the sense of "someone else can get them". They require physical access to my home. That's a heck of a lot more constrained than even my normal 2FA device, which is my phone. –  Nov 14 '19 at 12:43
  • Sorry for tiring you. Since I have to design a secure system myself, I try to thoroughly understand which vulnerabilities I have to be aware of. For all the rest of it, I think it is wrong that companies claim they have implemented 2FA when in fact, I think, they haven't. They may have implemented a secure system by any definition you like, but it isn't 2FA, if I understand everything correctly. – scola Nov 14 '19 at 13:19