It's the same idea with using a password manager in the first place - if a password manager is going to be the thing that gets you to use secure passwords that vary across services, it's worth the tradeoff of having all of those passwords in one place, because you're much more likely to be compromised by a bad password than by a password manager leak.
At the very least, you SHOULD keep the 2FA credentials in a separate database (IE, keepassxc can keep multiple databases), so an attacker would need to double their efforts to get both parts of the login.
There is literally no point to encryption if possession of the ciphertext is sufficient to extract the secret.
This is what I do for my keepass database. It means I can store my database in a cloud service of my choice for sync purposes too.
I use KeePass, never upgrade it, and only back it up to my own cold spinning drives. If malware stole my local vault I'd be in trouble, but it's more convenient than keeping my passwords on paper.
The reason for those losses was partially that LastPass was encrypting with extremely low iterations on long-standing accounts (it also may not have helped that they didn't encrypt URLs either). That was a terrible practice which isn't duplicated by credible alternatives.
As a matter of opinion you may still be right, though personally I consider the risks of a bad password to be higher than a leak purely because without a password manager making it simple to use long random passwords most do tend to be bad ones (duplicated/short/guessable/engineerable) as those are the only ones that are memorable.
It's the usual trade-off between security and usability, with the perfect being the enemy of the good, especially in regard to pushing less technical users to solutions which may not be ideal but are still much safer.
But why would it be better to use passkeys?
Because don't sites with passkeys generally still allow you to fall back to password, since it's common for people to lose their phone and then lose their passkey? Whereas sites with 2FA obviously don't, and have more complicated/secure recovery mechanisms?
So seems to me like 2FA (TOTP's) are currently vastly better in practice?
Tokens that increase the trust level of an authentication come with additional controls (tamper resistant hardware, passcode, etc)
For normal people, a FIDO token delivers the highest level of security and integrity.
In practice, I feel the main reason 2FA is popular is because people cannot be trusted to create unique and secure passwords for every service. The phishing-resistance is nice, but I'd prefer it being the only credential, and just having it be autofilled (making it longer to combat bruteforce), like what we currently have with password managers...
Here's to hoping passkeys turn out any better.
Right. This is the killer features of passkeys.
Then again, I do this for accounts that I really care about, I just keep TOTP in my password manager for accounts that are not worth the effort.
I get their argument that 2FA makes phishing more difficult, but I disagree that it's its "primary use", or that the distributed factor is unimportant. I personally wouldn't feel comfortable having all my important accounts behind Bitwarden's single point of failure. 2FA for important accounts mitigates the damage if my Bitwarden is broken into.
TOTP or SMS-2FA are obviously phishable, if you just entered your password into a phishing site, why wouldn't you also enter a TOTP code? I usually point to Modlishka as a practical example (https://vimeo.com/308709275) to help visualize this.
In fact, the main (claimed) advantage of 2FA is that it prevents "Credential Stuffing" of reused passwords. I personally don't think TOTP (or similar) are a good solution to this problem at all, but this is a thorny issue.
If domain doesn't match, and you manually copy the password, and login, you can as well manually copy the 2FA code.
Yes, same with the password.
So it is not an advantage of 2FA.
I'm curious though why you don't think TOTP or similar are good against credential stuffing though, would you be able to expand upon that?
> I'm curious though why you don't think TOTP or similar are good against credential stuffing though
I have written about this before, but looks like I lost the article somehow. https://web.archive.org/web/20210219185711/https://blog.cmpx...
Imagine you reuse the same password everywhere, and are sick of credential stuffing attacks. You ask your friend for advice, and your friend tells you to just enable TOTP when available, explaining that when there is a data breach you will be safe.
That is obviously bad advice, the vast majority of services do not use TOTP and you will have to race attackers to change your credentials quickly at dozens (hundreds?) of services. I think a reasonable person would say that you have not "prevented" credential stuffing.
A far better solution is unique passwords, it works today with all service providers.
A better approach would be to split in two solutions where you store passwords and 2fa keys.
I use bitwarden for passwords, but save all 2fa in aegis. These two have different 5 word passphrases prefixed with a regular 8 char password to increase entropy. I save a backup of the 2fa db to a replicated storage with a synthetic password. For bitwarden I delegate persistence of the data to bitwarden, but it would make sense to take encrypted backups regularly.
The disaster recover protocol is to have a smaller 2fa encrypted database printed in paper. I know the password to this db. Recovering this DB gives me access to bitwarden and the cloud storage, which gives me access to the rest of my password and keys.
A) Is fooled by a phishing attack
and
B) Is not fooled enough to manually copy-paste credentials from their password manager after noticing that the autofill didn't work
Does a person like this exist somewhere? Sure, if you interview 1 million people, I'm sure you will find 1 person like this.
It is very, very strange to me that the security "experts" are narrowly optimizing for this specific user and downplaying all the risks related to their recommendation.
I don't remember the exact number but something like 30% of people who didn't use a password manager got caught. Basically no-one using a manager was.
Granted there might be some selection bias (people who had managers were probably already slightly more security conscious), but people were feeling slightly embarrassed to have been caught and it worked great to have everyone do the switch. And everyone remembered after that that if it doesn't autofill, something's amiss.
Google Authenticator doesn’t export the seeds or store the seeds in the device backup, or sync them, so when you lose or upgrade that phone, you lose all your TOTP. This is bad.
Also, TOTP in general is bad, because it is easily phished, just like passwords. Using a password manager to store TOTP cuts down on phishing risk as it won’t input them into the wrong domain site. Copying them manually from a different app is still vulnerable to phishing.
Not true anymore. [0]
[0]: https://www.theverge.com/2023/4/24/23696058/google-authentic...
https://security.googleblog.com/2023/04/google-authenticator...
The problem with "phishing" is not the technology. Phishing is 100% a human issue and no matter what tech. you might use, those humans vulnerable to being phished will find a way to be phished.
[1] https://f-droid.org/en/packages/org.liberty.android.freeotpp...
Did you read the article? That's what they say.
> For maximum security, you can store your 2FA token elsewhere ... but for general purpose use, storing your 2FA in your password manager is an acceptable solution due to the convenience benefits it provides.
No, that's not what they say. If you read the text that you just now quoted, you will see that it says "storing your 2FA in your password manager is an acceptable solution due to the convenience benefits it provides". Clearly the writer of that text believes there _is_ something wrong with having 2FA completely separate from the password vault: it is less convenient, to the extent where they are happy recommending this horrible approach to laypersons.
In addition, if you go and read OP, you will find that they talk about the potential of losing access to your TOTP codes stored in Google Authenticator. So that's another thing that counts as "something wrong" with storing 2FA separately from password vault.
So there's at least 2 things in the article that count as "something wrong". So they definitely didn't say that there's "absolutely nothing wrong".
The problem is that it requires a certain amount of good hygiene when it comes to computer equipment. There are many people who are bad with computers, who don’t have phone backups and lose their phone, who will share accounts and devices, and so on. The result is an insecure mess.
So, solving the “people should use a password manager” problem requires solving all the other issues surrounding how non-technical people use and misuse computer equipment, so that having a password manager and not losing the essential data stored in it becomes the default.
For some people, it would probably be safer and easier to write down your passwords on paper, in a notebook. Other people will lose the notebook, or have it stolen from them. There are similar but more complicated issues with holding onto computer devices.
If someone can login via your Apple ID, which means that the person knows username/password, and can also convince you to provide them with 2FA code that gets shown on your existing device, they can just add a new device to your account, and get passwords to sync to it.
This is a special requirement for Passwords that does not apply to other encrypted data in your Apple account.
If all of my 2FA code generators had been in 1Password I would have been truly screwed, but in a stroke of luck I had been paranoid enough to use a separate app for 2FA codes.
The lesson here is using granular permissions and sharing things selectively, more importantly never giving master access to anyone.
I know this happens sometimes, and I’m thankful my partnerships have never gone this bad. Did you know it was headed this direction before he tried it? Was that the end of the company?
I “won” in the end — the board fired him and appointed me CEO - but it destroyed the company.
And yes, I saw it coming, but was hoping I could control him until we found revenue and the pressure came off. This was illogical because people like that cannot find revenue.
I know this doesn't necessarily apply to smaller companies and startups, but have lawyers write you strong contracts that aren't one-sided, but are full of protections for both sides, if they aren't sabotaging stuff.
If you’re on a small team (~5 people) the person obsessed with access controls cannot be trusted.
If any journalists are lurking in this discussion, this would make a decent article.
1. While a password manager should associate a TOTP seed with a domain and only fill codes on that domain, the codes are still visible to you. A convincing phishing attack might trick you into manually entering a code into a fake page. Passkeys don't allow this.
2. TOTP codes are derived from a seed shared between the client and server, so an attacker who gets read access to the server's database could generate your codes. With passkeys, the server can only validate a signature, not generate them.
I would bet there are some systems that accept a passkey in a situation that they don't accept a password.
If my device is compromised, along with my device's password, as well as the password manager's password, then yeah... I'm screwed.
As long as I keep my devices up-to-date though, I believe the highest risk comes from state-sponsored actors. I've chosen convenience, and I've made my peace with it.
They are often better than only using a password (merely due to the fact that most humans pick terrible passwords).
But using a password + 2FA generally is safer than passkeys. This is especially true if you use webauthn for 2FA, since now one of your factors is basically the passkey.
The time-variant component is still quite valuable, but it does nothing to protect you in the event of a password manager compromise. This is not a hypothetical; LastPass has suffered multiple breaches, and the more popular a solution, the more likely there are to be attacks against that solution. By keeping your 2FA separate from your password manager, even if it's still just "something you know", it's something you know in a location that's orthogonal to your passwords. If I yield to convenience and use a 2FA desktop app, then now, instead of just attacking my Bitwarden install, you have to successfully attack my Bitwarden install and my 2FA desktop app install to get access to my accounts, and the combination of password managers * 2FA managers is a substantially larger attack surface and requires a significantly more sophisticated attack to get both pieces.
The arguments in the article come down to "well, 2FA mitigates phishing attacks" (true) and "Google Authenticator means you can lose your data easily" (also true). But neither of these is a good argument for why the data should be kept together. It just means "use 2FA", and "use a 2FA manager that lets you directly manage your seeds and keep offsite encrypted backups".
If you can't be bothered to do it properly, then 2FA codes in your password manager is certainly better than not using 2FA at all, but that just makes it a less terrible solution, not a good one.
On a related notes, "passkeys" are also "something you know" for the same reason.
However, that does not mean that TOTP codes are useless. Not all "something you know"s are created equal. However, I shamelessly put my TOTP codes into my password manager. Just because some people mistakenly identified it as "something you have" doesn't mean I need to pretend they are correct. It just inconveniences me for no security gain.
That's not a useful distinction and needlessly breaks an otherwise useful model. By that logic, every authentication method is just "something you know" since every piece of information can be represented as a stream of bits, and password managers are well equipped for storing it. That includes your face, fingerprint, and DNA.
Yes, if you use a bad password manager that is fundamentally flawed (like LastPass) then all bets are off but that's not an argument against the principle of storing 2fa codes alongside passwords in a password manager.
I doubt there's a single Bitwarden user on earth who has ever suffered a security incident because they store their 2fa codes in Bitwarden, that's how inconsequential this risk is.
Passwords in the password manager are not "something you know" anymore. They are "something you have". So, no matter whether the TOTP codes are stored in the same app or a separate device, you can no longer properly call them 2FA. It's 2x "something you have" in either case.
EDIT: user "jerf" in the same comment thread says that it is 2x "something you know". The distinction whether something stored counts as "something you know" or "something you have" does not really matter. In either case, it is 2x the same type of a factor. --END EDIT.
From the "difficulty to compromise something" standpoint, you are, of course, right that storing the TOTP seed in a separate device is better. But look, this is not the primary reason why websites need to implement TOTP. The very fact that hackers need to compromise your device in order to get access to your account is already indicating a higher-than-usual security level, even without 2FA, and the article fails to notice this. Besides, the article only presents a user-centric viewpoint, while the viewpoint of a website owner would be more relevant here.
The main problem solved for real by TOTP is that users select stupid passwords like "Zhong+wen" that are guessable yet still pass complexity requirements, or reuse passwords on multiple websites (and your website cannot check for that), thus enabling compromise of the user's account on your website if another website gets hacked.
The main security reason (from the website viewpoint, not from the user's viewpoint) for TOTP introduction is, thus, to introduce a high-entropy factor which is (unlike a password) not chosen by the user, guaranteed not to be reused elsewhere, and thus cannot be guessed or compromised without access to the user's devices. This benefit is not invalidated by you storing the 2FA secret in the password manager.
People often skip out on actually assuming responsibility for their data and accounts. A backup system should be in place and ensuring their 2FA codes are not lost with their device is part of that taking on responsibility.
People take the path of least resistance; we know this. It's why, for the longest time, people used one password for everything. People don't like using password managers, either, but we would all agree that it's unacceptably insecure to not use them, because the alternative is "one password used everywhere, maybe with a single varying digit on the end".
You can mitigate this risk by not depending on your password manager app to do cross-device sync..keep a file on Dropbox/OneDrive/iCloud Drive/SFTP/etc and use an app like KeePass/Strongbox/etc that just deals in managing credentials.
My KeePass file storage provider doesn't know what the hell I store there because it's encrypted (I hope there are no known issues with KeePass's crypto)
As a bonus, you can keep offline backups to mitigate other risks like house fire, lightning strike induced EMP frying things (happened to me), storage vendor goes out of business, and more.
-------------
I think in the end, there is no universal solution - you really have to try to be reasonable about estimating your own personal threats and risks (such as asking "am I more likely to suffer a password manager compromise or more likely to break a device?") to decide whether to keep 2FA next to passwords or not.
The argument is "because many people, if they can't keep the data together, will elect not to use 2FA at all if given a choice."
Any decent password manager would avoid autocompleting the password on the wrong domain in the first place. I.e.: it will already protect against phishing attacks anyway.
1Password's documentation use to have a whole article about how bad an idea it was to store TOTP in a password manager — but their stance completely changed at some point. Around the same time they started _recommending_ that you do so, and presented it as a key feature in the marketing material.
---
Personally, I think that the only valid reason to store a TOTP secret in password manger is when you don't really care too much about an account (e.g.: prefer convenience over security), but the website demands that I set up 2FA.
If someone has my password and my device how will a separate app help me in this case?
Honest question as the 1password model seems to be “something you know and something you have”.
A "2FA Mule"[1] solves this problem by staying in one place with constant power.
I receive plain old SMS 2FA codes while flying in an airplane.
I also don't care that much if I lose or destroy my personal mobile. In fact, I don't even know my current SIM number. If I lose my personal mobile I just edit a twiml bin at Twilio and point my number somewhere else ...
There's lots of cases where 2FA reduces to 1FA. E.g. logging into a website on your mobile phone, and getting your TOTP or SMS code on that same phone. In fact-- that case is so common I wonder if we should just get more used to the idea of 1FA, with smartphone passkeys/biometrics/SSO being the auth factor. As it stands, if you compromise someone's smartphone (and have their smartphone PIN), the odds are great you can autofill any password you like on their phone and pull up any needed 2FA tokens as well.
1. The key is generated by the server, not the client (human), so it cannot be reused like a password.
2. The authentication is temporally bound, so phishing only offers access for ~30 seconds, unlike a password where it provides unlimited access until someone changes it (never unless forced in practice).
3. It's literally required for many services, so you need to use it. The alternatives to storing your secrets in your password manager are keeping them on your phone (which is how most people log in anyway, so its already becoming a single point of failure) or using something like SMS 2FA, which is even worse as SIM jacking is pretty trivially possible on most providers.
Backing up TOTP seeds encrypted is a good idea if you know what you’re doing.
It is a security-improving move when humans are factored in, not a trade-off between security and convenience.
I wonder why service providers don't have it already. They could even help ensuring that the passwords are different and provide some interoperability between both vaults (e.g. TOTP on mobile device is passed to PC password completions)
Currently, bitwarden stores these encrypted, but they are unlocked with the rest of the password manager.
For now I'll stick to yubikey for 2FA.
But I wish I could use bitwarden as a layer of abstraction, such that bitwarden would always require my yubikey before allowing any of the passkeys or totp keys to be used.
Or, when the author says “save the 2FA code” does he really mean “use the password manager to generate the 2FA codes”?
In the early days of MFA that thing meant a cellphone because it was SMS by default, but yeah, a laptop or computer of any kind is a "thing you have" as well.
https://github.com/kardianos/safekeysheet
It could be modified to also print out the otp as well if stored.
It does require some thought / hygiene but seems a fair compromise.
Storing 2FA codes in your password manager is not a good idea at all in case you get it breached. Otherwise it could be a convenient idea.
If your password manager gets breached you could also loose control of your 2FA as it can be replaced as well.
We need to securely store our 2FA codes, sure. But I would advise not to use the "normal" password manager. I for use have them printed on paper.
Is that supposed to be remotely difficult? It'll take maybe an hour to whip up a script that takes the captured credentials, passes it onto a headless browser to attempt the login, capture the session cookie, and optionally refresh the page regularly to keep the session active.
