Hacker News Reader

Comment by marcan_42 | Hacker News Reader

Please don't put TOTP codes or back up codes in password managers. The whole point of 2FA is to have two factors protecting you. If you do that, you're back to 1 factor (your password manager master password).

View on HN

I have that debate inside my head often, but ultimately it boils down that "security" is a spectrum and convenience is on one end of the spectrum. Having all passwords be "asdfasdf" is massively convenient, massively insecure. Having to carry my titan key with me all the time (assuming my suck ass financial institutions even allow WebAuthn) is massively inconvenient, and pretty secure.

I'm 100% on board with not using 1P's TOTP for guarding the AWS Master Payer Account for my company, but my GitHub account is not a nation state threat, so having 1P autofill the code after it autofills the long password is very convenient

I have also experimented with passwords in one manager, TOTP in another, but ... as I said about that convenience spectrum

---

Kind of related to that last item, I also have gotten a lot of mileage out of KeePassXC's autotype feature for having it type my GPG pass phrase into pinentry. It stays out of the clipboard, I only have in use it within the pinentry timeout, and it's convenient. I wish 1P had similar behavior on sane OSes (1P will autotype into certain fields on Windows 10 but that convenience extends only to my gaming accounts because I'm not going to use Windows)

But wouldn't it be even more convenient to just not use 2FA in the first place? If you're just going to store your TOTP seed in the same place you store your password, why even bother?

If a crappy website’s user database gets attacked, the hacker may have my plaintext password stored in it. They may not have my 2FA seed, so there’s at least a chance that the attacker still may not be able to access my account.

I think this is much more likely than an attacker cracking my 1Password vault.

Your point is true, but it is highly unlikely that a website providing 2FA would also be storing passwords in plaintext.

Wouldn't the TOTP seed be stored in the same breached database? Where else would they store it?

In my case, I actually enable 2FA mostly for convenience, rather than security. I often log in from different country IPs (VPN), I auto delete cookies, often use private mode, etc., so some websites are frequently suspicious about my login and ask me for an additional step to verify, e.g. by asking an additional question or sending an email with a verification code. There is usually no way to manually disable this additional check; nor do websites seem to learn that logging in from different IPs with no cookies is my usual behavior. Enabling 2FA makes websites have more trust in my login, so I get none of those additional verifications, with no additional inconvenience as 2FA stored in password manager and typed automatically just like the password. So in a way I enable 2FA in order to disable 2FA.

I would think 2FA-in-masterdb still protects you against some website hacks, most browser exploits and phishing sites, using your password on other potentially compromised devices (public wi-fi, work, etc.) and probably some keylogger scenarios that would miss the database content.

It seems your threat model just doesn't match mine, and I'm glad you have the emotional energy to pull out your phone to auth to every website. Yes, sure, if some rando joker exfiltrates my 1P vault and keyloggers my machine, fine, they get all the things for all the things, but that's Security Darwinism at work if I allow that to happen

> you're back to 1 factor (your password manager master password)

That's only true if you are using an online service as a password manager, so the master password is the only thing protecting you. Not necessarily for offline password managers. E.g. in my case, I use Keepass that I never sync/store online, so even without enabling a website's 2FA, for many attack models I am effectively using 2FA: logging into the website requires both something I have (a device with my Keepass database) and something I know (the password for my Keepass database). But without website 2FA those two factors then produce one single factor (the website's password) that is transmitted to log in, so enabling website's 2FA and storing it in Keepass makes it 2FA against even more attack models, i.e. attacks where it's not my password database that it compromised, but just that one password. So it's still a benefit.

If I ever feel the need to sync my Keepass database, e.g. on Dropbox; I could set a key file (that I transferred offline between my devices) in addition to the master password to preserve this 2FA aspect, so that even if my Dropbox password and Keepass master password were both compromised, they would still be useless without access to my devices that contain the key file. But I never had the need to use my password manager on a different device, so no syncing needed so far. In any case, I don't actually care about 2FA (when I enable 2FA, I actually do it to decrease security, not increase it, as I explained in my other comment), this 2FA is just a bonus of my not needing and liking online services.

In which case would attacker be able to compromise your password but not the 2FA code? Eavesdropping on an unencrypted channel would be one, but given how ubiquitous https is, it's hardly a concern.

Most likely there would be a breach on the site's database, where all password hashes, and the TOTP seeds are stored. In that case, having 2FA or not doesn't make any difference.

2FA is usually useful if the user is not confidence of the integrity of his login device, e.g. public library computer. If you are perfectly confident of your own device, there isn't really any point of having 2FA.

The only cases that I can think of are me doing something stupid, like posting my password somewhere public by mistake (e.g. using KeePass password auto-typing on comment field instead of password field, or pasting it in a wrong place if I am copy-pasting), or a phishing attack where I foolishly insist on copy-pasting my password when it doesn't auto-type. But even in those cases, 2FA would indeed be of very limited help since:

1) In the first case, chances are that I would realize this immediately and change my password, which I would have time to do as there is no actual attacker yet; only future opportunistic attackers. 2FA would be useful only if I not only pasted my password and 2FA code, but then not even realized it. Then 2FA might help since by the time anybody notices this, the 2FA code would be invalid.

2) In the second case, if the phishing attack is not real-time (i.e. attackers are just recording my credentials instead of immediately logging in in my place), 2FA would help since the 2FA they stored would be invalid when they tried using it. 2FA is less helpful in a real-time phishing attack; though having 2FA might still help since changing my login credentials would presumably require another 2FA code so at least they can't lock me out (unless they can convince me that I need to enter another 2FA code, which I guess is possible if I was absent-minded enough to fall for it in the first place).

In any case, I don't worry much about these scenarios and I agree with you about 2FA, that's why I don't usually bother with it except in cases where websites freak out because I keep logging in from foreign IPs with no cookies. Then 2FA is useful because it makes the website trust my login, at no additional inconvenience to me as KeePass auto-types 2FA code just like my password, so I don't mind enabling it when I can.

This isn't quite true. 2FA still protects you from password breaches (and weak passwords, though you shouldn't have those if you're using a password manager).

Also, keeping 2FA codes in a syncable password manager is a huge boon for people who ever break/lose phones. Can't tell you how many people get locked out of their accounts because they lose their 2FA codes.

As an alternative, companies have to have a 2FA-reset process. The fact that such a system exists weakens the entire system, which is too bad.

TOTP-based 2FA wouldn't protect you against a password breach, since the breach would most likely include the TOTP seed alongside any password hashes.

WebAuthn-based 2FA would; but AFAIK there isn't really a way to store WebAuthn keys in password managers at the moment.

I was curious about that, so I looked into it; KeePassXC is having some mixed messages about it:

https://github.com/keepassxreboot/keepassxc/issues/1870 says "awesome!"

https://github.com/keepassxreboot/keepassxc/issues/1996 says "go away"

and I can't figure out what is going on with https://github.com/keepassxreboot/keepassxc/issues/3560

They reference https://github.com/kryptco/kr-u2f in one of the issues, but it was bought by Akamai and the code was never under an open source license to begin with :-(

If you use a password manager that's two factor, then you are still at two factors. e.g. vault-based or hardware key based

I justify the second factor as having the 128-bit security key for the vault.

It's not that easy to install a 1Password vault onto a new device, so I'm okay with the 2FA codes getting stored in the same place as the passwords and sync between.

The realistic scenerio for my passwords leaking is target database exploitation or MITM attacks and not vault exploitation. The 2FA is still a rolling phrase that makes any capture of my password useless after about 1 minute, and not only that but I actually even get email notifications ('xx logged in from a new device') if someone uses my password but can't get past my 2FA. It feels very secure and I reject the dogma that 2FA means 2 separate physical devices.

I manage a password manager for an MSP that supports hundreds of Azure tenancies with dozens of engineers. 2FA codes in the password manager in a shared space is far safer than a non synchronised account with no 2FA. Since the TOTP code is not accessible too, it also means that password manager breaches are time limited.

Just depends on your use case.

Reply on news.ycombinator.com