[StrLght]

> negates the advantage of two factors authentication

Like with all things it depends on your threat model.

If your threat model includes risk of leaking all data from your password manager – then yeah, it worsens your security.

Otherwise it still covers all other risks:

1. it makes bruteforce basically impossible

2. it makes phishing harder (assuming that your password manager supports autofill and that it checks domains correctly)

3. it lowers the risks if a single password leaks

[Aachen]

All of this is true without 2FA, just storing securely generated passwords in the manager.

Whether it negates the benefits of 2FA (i.e. whether it's 1FA) doesn't depend on the threat model. The threat model is what makes an individual decide whether 2FA is worth it

[brnt]

No? Without TOTP in Keepass, an attacker still only requires a password (which may be brute forced or otherwise obtained from badly secured websites). If you have TOTP, they _also_ need a copy of your keepass-file, the password and any other factor to _it_, or have access to your machine during a session or so.

[Aachen]

Think about how the attacker gets there:

- "an attacker still only requires a password (which may be brute forced" Brute force? Then it wasn't generated securely. Use Keepass' built-in generator or another one that is meant to generate passwords with. You could make the same argument for the 2FA seed: that can also be generated insecurely or set manually by hand

- "or otherwise obtained from badly secured websites" The attackers can obtain the 2FA seed in the same way. Furthermore, the 2FA seed is stored plaintext in the website's database whereas the password is typically stored in hashed form (which is unbruteforceable if you generated it securely)

- "they _also_ need a copy of your keepass-file, the [main] password" The attacker either got the website's password from this same file (so they evidently have that file and the main password to unlock it), or if you imagine a scenario where the site got hacked and the stupid site stored your password in plain text, then they have access to the site (and the 2FA seed) anyway because they hacked it. So long as you don't re-use passwords (don't need 2FA for that, just a password manager), a site's breach has no impact beyond this one site that was hacked outside of your control

- "and any other factor to _it_" Do you mean the key file here? Or what other factor? Either way, again: if they need that to open the vault then they can't get at the passwords either, so what benefit does {2FA when stored inside the password vault} have?

I don't know of a scenario where an attacker can get the website's password from the vault, but not the website's 2FA seed, when you store both inside that same (encrypted) file

[brnt]

1. TOTP (the only 2F we could be discussing) is derived in a specific way by e.g. Keepass, which has been audited. There is an RFC for this. I don't see the vuln here. 2. But this info is transferred just once, so the method relies on either intercepted both (pw and TOTP seed) that one time. Far less likely than intercepting just the pw every time you login. With a compromised or insecure server: all bets were off already. 3. Even if you have safe service-dependent passwords, as one should, 2F renders it useless in certain scenario's, if all they have is the password. 4. Yes, factors to the keyfile. It does not have to be just a password.

While it seems a reasonable assumption that 2F seed and password are stored alongside eachother, the vuln does not need to expose both. We don't know. But we do know more factors means more opportunity for 1 factor to be accidentally safe.