24

I wonder whether it is really secure to store the Two Factor Authentication seed code (e.g. the secret key for TOTP) within a password manager together with the user and password for the service.

If someone gets access to the decrypted password database (e.g. while the password manager is unlocked or by brute forcing the master password), the attacker also has access to the TOTP token which makes Two Factor Authentication pretty useless.

In my eyes, storing the Two Factor Authentication code in the password manager is everything beyond secure.

Duncan Jones
  • 1,647
  • 1
  • 10
  • 14
Programie
  • 341
  • 1
  • 2
  • 4

4 Answers4

20

I don't think it's as bad an idea as you assume. Think about what threats you're trying to guard against by using TOTP, and think about what attack scenarios are made easier (or not) if storing the TOTP seed in your password safe.

With the seed in your password database, TOTP will still guard against:

  • Password breaches of the website where you hold your account
  • Keyloggers on untrusted computers (on which I assume you will not actually run your password manager, but rather read a password off a trusted device and type it in manually)
  • Network captures on open WiFi networks, etc.
  • Phishing/social engineering of you, the user

Things which are NOT guarded against include:

  • Social engineering of customer service/tech support of the website owner
  • A stolen password database and master password

The first case cannot be helped regardless of where your TOTP seed is stored. The second case deserves some additional consideration. Specifically, how can your database and master password be breached? Either:

  • The attacker obtains a copy of your database from cloud storage, or a discarded backup, and cracks your master password. A strong master password (80+ bits of entropy) and secure implementation of a KDF on the part of the password manager developers should completely prevent this attack.
  • The attacker puts malware on your machine which is specifically designed to target your password manager. But consider: if you have such targeted malware on your machine, why not write malware to hijack a browser session? Or force-install a browser extension to steal all the desired information? Or install a custom certificate to allow a MITM attack? A browser extension could even display pages making it look like you were simply logging into the site again, whereas in reality you were providing the credentials needed to disable 2FA entirely!

Now, some caveats: there is ready-made malware (or at least proof-of-concept code) out there which can already target specific password managers. I'm not aware of any ready-made malware that interactively takes over an account to disable 2FA.

But the point is, the only scenario where the TOTP seed causes problems for you, is a scenario that would also cause problems even if your TOTP seed was stored elsewhere. With that in mind, I've not seen any convincing arguments against keeping the TOTP code in my password manager, especially for password managers that can use the TOTP seed to generate the codes for you in place of Authenticator, Authy, etc.

Recent events have brought to my attention a scenario I did not consider above: if you store an account in your password manager, which you only ever access on specific systems, you can expose yourself to increased risk by storing the 2FA code for that specific account in your normal, synced-everywhere, day-to-day password vault.

Specifically, I'm referring to the continued fallout from the late 2022 LastPass breach. It came to light recently that a senior DevOps engineer at LastPass had their personal password manager data stolen from their home computer. From there, the attackers extracted login credentials for a corporate vault that only 3 other employees had access to: https://arstechnica.com/information-technology/2023/02/lastpass-hackers-infected-employees-home-computer-and-stole-corporate-vault/

Now, the article does not specify whether the corporate vault was protected with any sort of 2FA, or if seed values for TOTP-based 2FA for this vault were stored in the engineer's personal password manager. It also doesn't specify whether the engineer ever used this corporate vault from their home computer (but that seems unlikely). The level of sophistication and persistence these attackers showed, and the high value of this engineer's account, imply that this person may have been compromised eventually even if they did have 2FA codes stored only on their phone. HOWEVER, the event raises the following plausible scenario in my mind:

  1. You have a sensitive account which you access only at work (or similar). You do not (or maybe cannot) access this account at home.
  2. You sync your password manager between home and work.
  3. You store your work-only account password and 2FA key together in your personal password manager.
  4. An attacker completely pwns your home computer, while you access your personal vault at home.

In this very specific scenario, your work-only account is indeed at increased risk of exposure. Presumably, corporate assets are protected better than your home computer and are less likely to have vulnerable media player software and the like installed so their attack surface is reduced.

If you have accounts you only ever access from specific devices, storing both the password and 2FA seed together in a vault accessed from multiple other devices does probably degrade the security of that specific account.

HOWEVER: as before, storing the 2FA code in an encrypted vault on the same device you use to login doesn't really add risk. Looking at how this engineer's personal vault was compromised, 2FA did not help at all. It didn't matter if they had stored their 2FA seed in their vault, or on their phone. The attacker was running malware locally on the computer the engineer was logged into, and was able to bypass MFA simply by waiting for the engineer to enter the MFA code themself.

I assume that most people generally do not have high-value accounts only accessible from specific devices, where they login using their vault shared with other devices. If you are one of the high-value targets holding keys to a high-value asset, it is probably wise not to store password and 2FA seeds together on some other less secure device. If this very specific scenario does not describe you and the account you are protecting (I assume this is the case for most people), then refer to the previous analysis.

Ben
  • 4,032
  • 1
  • 12
  • 23
  • 4
    I would argue good security requires you to assume nothing is flawless. TOTP is one way to add an additional layer that requires a separate compromise. Putting your TOTP seeds in the same place as your credentials will collapse the "something you have, something you know" construct down to "something you know". You are then entirely dependent on the security of one system - the password database. This doesn't seem wise to me. – Duncan Jones May 20 '17 at 06:36
  • 1
    Well, you still need to obtain a copy of the password database as well. A simple phishing campaign or MITM will not be enough. I'm not depending on the security of only one system, I'm depending on at least two: first, I'm depending on my PC not to be compromised. Second: I'm depending on my password database being secure. Compare that to TOTP on a second device. I'm still only depending on two systems: my PC is not compromised, and my phone is not compromised. It's not removing an obstacle, it's replacing it. The phone storage of a TOTP seed is often not encrypted at all, or only weakly. – Ben May 22 '17 at 15:17
  • 1
    If the password database is compromised then you're doomed surely? You are dependent upon only one system if your TOTP seeds are stored in it. If I somehow compromised LastPass, for example, I would have peoples credentials and the means necessary to generate their TOTP tokens. They wouldn't even know I was doing it, until LastPass discovered the breach. – Duncan Jones May 22 '17 at 18:47
  • You'd also be doomed if an attacker compromised your phone. It goes from "must compromise my phone" to "must compromise one of my devices" if I store the seed in my database. And my database is encrypted better than my phone to boot. – Ben May 23 '17 at 03:34
  • 1
    If an attacker compromises my phone, they could access my TOTP tokens, but not my credentials. If I'm practicing good security, I won't use my phone to access the sites protected by the TOTP seeds. So the attacker still has to crack the password database separately. This is the very essence of 2FA. – Duncan Jones May 23 '17 at 07:44
  • 3
    As stated in the answer, you're still going to be vulnerable to a compromised PC even without storing your seed in your password database. And a compromised PC is really the only scenario you need to worry about with a strong master password and either a local-only password manager or a "zero knowledge" cloud-based manager. – Ben May 23 '17 at 14:50
  • "[A] secure implementation of a KDF on the part of the password manager developers should completely prevent this attack." Wouldn't using a separate device to store the OTP seeds make this assumption unnecessary? @Ben – sourcream Jan 08 '23 at 16:49
  • Well, yes, but your master password strength is entirely under your control. And that does reinforce the importance of choosing a good password manager! – Ben Jan 21 '23 at 01:26
  • 1
    i don't get it, isn't the point of 2FA to use 2 factors to authenticate a user? so if both are stored in a single password database, secured with a just a single factor (a master password), doesn't that reduce the number of factors needed to authenticate to 1? – Fuseteam Feb 03 '23 at 16:19
  • In that case the 2nd factor would be having a copy of the database file, which normally means having one of the devices belonging to the user. And, a password database itself can be secured by multiple factors. For example in order to download and use my 1Password database from the 1Password servers, an attacker would need: (1) my password, (2) the "secret key" generated for my 1Password database, and (3) the 2FA code for my 1Password account. – Ben Feb 08 '23 at 19:26
  • @Ben if using a separate device can make you drop one of the assumptions you made, then there is the advantage of using a separate device. You don't need to trust a password manager as much as you do if you store your 2FA seeds in there. – sourcream Mar 29 '23 at 17:25
  • @sourcream I'm not sure which assumption you refer to, because as I've laid out, in most scenarios where your password database can be compromised, the same attacker could easily compromise the accounts the password manager protects regardless of where the 2FA seed is stored. But yes, I acknowledge there are scenarios where storing the code separately may be more secure than storing it in the same database as your primary credentials. But that does not make 2FA auth "pretty useless" if stored in the password manager, nor does it make it "insecure". Only marginally less secure. – Ben Apr 03 '23 at 11:37
  • @Ben "in most scenarios where your password database can be compromised, the same attacker could easily compromise the accounts the password manager protects regardless of where the 2FA seed is stored". Do you have any evidence for that? How does a badly secured password manager database (as was the case of LastPass, see an analysis here) automatically translates to an attacker also having the ability to break 2FA if the seeds are stored somewhere else? – sourcream Apr 04 '23 at 19:31
  • @sourcream, read the answer you're commenting on. That's what I'm referring to. The LastPass breach wasn't the type of "password database compromise" I'm talking about. If your master password is strong enough, your LastPass database is not compromised even if the attacker has it. Granted, they screwed up their KDF so your password may have needed to be stronger that it should have needed to be, but I'm referring to cases where a database with a strong enough password could be compromised. If your database password is crap, sure, storing 2FA codes inside (or passwords) is not a great idea. – Ben Apr 06 '23 at 15:42
  • @Ben The LastPass breach is a reminder that password managers cannot be fully trusted. Sure, in that specific instance, if you have a strong password, then your data is safe. But what if the database was not properly encrypted? Then you would be grateful to have your 2FA seeds elsewhere. – sourcream Apr 06 '23 at 20:45
  • I read your answer very well, and my comments are here to alert anyone reading it that it's based on a strong premisse: that password managers will never give away your passwords in plaintext. Once you leave that premisse out of the table (which by now should be clear it is a plausible thing to do), then you should consider not trust all your eggs in the same basket. – sourcream Apr 06 '23 at 20:45
  • @sourcream, what password manager has given away your passwords in plaintext? As far as I know there has been no such breach. The LastPass incident may have compromised a handful of people with very weak master passwords...we haven't heard it if they have. And LastPass has had questionable security record for years. I haven't recommended them since they were purchased by another company the 1st time. It does in the end come down to trusting your password manager is implemented properly, but that's no less likely today than it was before the LastPass breach. Plus you can always go with KeePass. – Ben Apr 08 '23 at 03:10
  • @Ben not everyone will assume a “bad event will never happen” on the grounds that “that event has never happened before”. The LastPass breach was so egregious that one can imagine a worse scenario with passwords in plaintext being leaked. In fact, from that breach we learned that metadata, such as URLs, weren't encrypted at all! And they are a major player in the PM landscape, so from that one can reasonably conclude that managing passwords is not a simple task and decide to be more cautious. – sourcream Apr 09 '23 at 23:58
  • And yes, you can use an arguably more secure PM such as KeePass instead of LastPass. And you can also do that and leave your seeds in another device just in case you’ve misjudged the infallibility of the PM of your choice. – sourcream Apr 09 '23 at 23:59
10

Assuming you mean the initialisation code for a given 2FA series, such as required when you first configure a TOTP generator for a specific service, then yes, storing it with the other login details isn't ideal.

As you say, should someone gain access to the password safe, they'd be able to log in without any hassle by using their own TOTP generator with the same initializations.

If you wanted to keep 2FA initialization values, a second password safe, kept apart from your day to day one wouldn't be a terrible idea, but you wouldn't want to keep the password in the main safe! Since you should only require the values very infrequently, they don't need to be as easily accessible. Even a print out in a safe may be acceptable.

Some services allow you to generate one use codes to regain access to your account in the event of 2FA device loss or failure. In that case, it's probably better to rely on those, rather than keeping the initialization values around, since they usually can't be used to gain access without a notification being sent.

Matthew
  • 27,381
  • 7
  • 91
  • 103
6

Storing TOTP seed within the password manager means: Anyone who gains access to the information stored in your password manager can circumvent 2FA completely and has access to everything.

Not storing TOTP seed within password manager means: Anyone who gains access to the information stored in your password manager can not circumvent 2FA and still cannot access every account you have that is protected by 2FA.

"Complete access to everything" vs. "still no access to 2FA protected logins".

That is a big deal and I felt a need for this answer since that is what it all boils down to.

Having TOTP seeds stored separated from the rest gives you more security and has no drawbacks at all when talking about security compared to storing TOTP seeds in your password manager.

The only gain you have from merging it all in the same place is quality of life. At the price of security!

Ralf Mckenzie
  • 61
  • 1
  • 1
  • 1
    Correct me if I am wrong, but some services do not support account access recovery when you loose the seed and a recovery key. Not storing the totp seed in the password manager has the drawback that you might not be able to recover access to some of your accounts when you loose (access to) your totp seed. I think this is more than just a "quality of life" improvement if this is something central like your email account. On the other hand it might be preferable to be locked out of your account if you loose your seed rather than someone else gaining access when he gains access to your vault. – Gamer2015 Feb 03 '22 at 13:04
  • @Gamer2015 "Availability" is a sometimes underrated part of the CIA triad, for sure. :) – Ben Feb 08 '23 at 19:31
  • I was going to write this answer before I came across yours. It's a fundamental convenience Vs security tradeoff. Thanks for writing this answer that needed to be here. – the_new_mr Jan 02 '24 at 07:41
1

I would just want to mention that GitHub on the topic of 2FA does state:

To keep your account secure, don't share or distribute your recovery codes. We recommend saving them with a secure password manager [...]

If you are already following the GitHub advice (GitHub is along many other websites that also advise this), then also storing the TOTP seed in the password manager would not be a security concern.

In addition most modern password managers support the generation of the TOTP if they are storing the TOTP secret, this actually increases security in practice, because you no longer need to "trust" specific devices since filling in the TOTP is not a burden.

apokryfos
  • 119
  • 5
  • Where in this answer do you address the seed and not just the recovery codes? Every mention has been about the recovery codes. I didn't need clarification because your focus was on the wrong thing. – schroeder Jul 06 '23 at 09:44
  • @schroeder I have edited to clarify. My point is if you are already storing the recovery codes then storing the seed adds security (under the assumption stated) – apokryfos Jul 06 '23 at 10:01
  • This still needs a lot of explanation as to why you think this is true and what relevance the Github quote might have or even the last paragraph. All you've said is "allowing your password manager to generate TOTP codes is more secure if you also store your recovery codes in the password manager". You don't explain why at all. – schroeder Jul 06 '23 at 10:10
  • And you are also assuming that the context is the Password Manager generating TOTP. The question is about storing the seed. That's a more specific concern. When this question was asked, Lastpass was allowing users to store their TOTP seed from their Lastpass authenticator in their Lastpass vault so it could sync across devices. So, it's not the Vault that's generating TOTP codes, but a storage solution. – schroeder Jul 06 '23 at 10:15
  • @schroeder today most password managers support generation of TOTPs. The answer here is to point out that if you are already storing recovery codes in your password manager, storing the TOTP secret is at least as secure, if not more secure than using a separate authenticator device. It's a very specific use case on purpose because it applies to alot of people since it is what websites recommend you do with your recovery codes to begin with. – apokryfos Jul 06 '23 at 10:26
  • So, your entire advice is based on a specific pre-condition: that you store your recovery codes *in the same password manager* as the TOTP seed. That's not what Github says (they aren't that specific). In fact, Passwordbits, Bitwarden, and other sites are very clear that recovery codes should be stored in an alternate place than the same password store as the one generating TOTP. So, an alternate place, perhaps even another password store. So, all-in-all, I think this answer is faulty, hyper-specific to a narrow understanding of the advice given, and misunderstands the issues involved. – schroeder Jul 06 '23 at 10:50
  • In short, you focused too much on recovery codes to a point where it doesn't make sense, makes an error in logic, and isn't helpful to understand the risks. – schroeder Jul 06 '23 at 10:51
  • So, I would like to point out that my original deletion was not in error or due to a lack of understanding of the concepts. Your answer made no sense. And the question had nothing to do with recovery codes. – schroeder Jul 06 '23 at 12:31
  • @schroeder to be clear, I deleted my answer because I don't have the energy to get into this argument. The answer is not about recovery codes. It is about storing the TOTP secret in the same password manager that you also store the recovery codes in. You may not like the answer or find it to be a bad answer to this question, but it is not irrelevant to the question. There is an entire process that an answer needs to go through before it's deleted if it is indeed irrelvant, as you say, and you sidestepped it. I find that to be abuse of moderation – apokryfos Jul 06 '23 at 13:43
  • Mods do not delete wrong answers. I haven't deleted this one. The original version was simply not an answer. And I am well within my power to delete non-answers. You flagged and I *undeleted it* so that you could explain. You ended up providing some kind of connection to TOTP seeds, and, although wrong, I kept the answer up. Nothing has gone wrong in the moderation process. – schroeder Jul 06 '23 at 13:55