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.


4 Answers 4


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.

  • 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. May 20, 2017 at 6: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, 2017 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. May 22, 2017 at 18:47
  • 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. May 23, 2017 at 7: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, 2017 at 14:50

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.


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!

  • 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 3, 2022 at 13:04
  • @Gamer2015 "Availability" is a sometimes underrated part of the CIA triad, for sure. :)
    – Ben
    Feb 8, 2023 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 2 at 7:41

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.

  • 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 6, 2023 at 9: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 6, 2023 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 6, 2023 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 6, 2023 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 6, 2023 at 10:26

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .