The 2FA part in the password managers (and least in the major players currently) is to get a copy of the encrypted vault from the server. The user did that part, and the encrypted vault was not easily accessible locally.
Even if the 2FA was used for decryption, it wouldn't really make you much safer, because malware can steal the decrypted vault out of memory right after you type in the 2FA. A HSM would solve this, as long as the HSM has some out of band way to communicate with the user, such as an approval button that malware can't press and a screen saying what password to release.
If the second factor is stripped for some arbitrary time, you don't have 2FA anymore. Your argument that "any adversary can read the vault from memory" is a weak one, we might as well not have passwords with that attitude.
The point of a second factor is that BOTH need to be present to get to the secrets. If one of those factors is stripped away for "convenience" we're misunderstanding the point of 2FA entirely. I can't make this any clearer.
It all comes down to threat model. If you don't have malware on your machine, 2FA and passwords are quite useful. If you do have malware on your machine, they're basically useless. This is basically the same for any service. Name one website or program that's safe even if you have malware on your machine.
>If one of those factors is stripped away for "convenience" we're misunderstanding the point of 2FA entirely. I can't make this any clearer.
It's not for convenience. It's because there's no practical way to implement encryption/decryption with 2FA. You seem to think there's some practical way to do it, but there isn't.
Lastpass 2FA protects against the threat model of an attacker who has stolen your password. In that case, the attacker cannot steal the contents of your database because the attacker can't get any form of the database, encrypted or decrypted due to not having the 2FA. Unfortunately now that an attacker has stolen all the encrypted databases by compromising Lastpass itself, this threat model is no longer realistic against this one specific attacker or any attackers that this attacker shares the loot with, because they now all have your encrypted database.
It is an implementation detail of the password manager itself. Any password manager can update their implementation to ensure the second factor is always needed when decrypting the vault. I'm not sure why you think this is an impossible feat. It's a choice that can be made.
The only thing I know that does encryption with 2FA is https://keepass.info/plugins.html#otpkeyprov . But I highly doubt it has much usage. It's going to be annoying typing in a 2FA every time you decrypt your password database (I decrypt my password database maybe 10 times per day). More concerningly, if you press the button on your 2FA device (this is HOTP, which requires you to press a button to get a new code) too many times, or typo the 2FA too many times, you can permanently lose access to your database because the HOTP device will advance past the point that the database supports.
So yes, it's a choice that can be made, but it has very major downsides.
And its not so much about protecting me, but to protect company interest right?
https://keepass.info/plugins.html#otpkeyprov
But this is beside the point I was making. My point was that even if the the database was encrypted with 2FA, right after you enter your 2FA malware can steal the decrypted database out of memory.
> right after you enter your 2FA malware can steal the decrypted database out of memory.
There's probably a creative protection here where each key is encrypted individually, but you'd still need some solution like the above HOTP trick or the attacker could scrape the key information out of memory, then decrypt each entry individually.
It seems to me like that would require a separate HOTP device for each password database entry, otherwise the malware can steal one HOTP token and use it against a different entry.
That would be a paranoid level of implementation. As it sits, the HOTP device is only _sometimes_ needed depending on the caching policy. Fix that broken implementation first, then we can figure out how to update the threat model to account for an adversary that has already infected your computer.
I don't understand what you mean. Are you talking about https://keepass.info/plugins.html#otpkeyprov or are you talking about LastPass? LastPass doesn't support HOTP AFAIK. HOTP isn't a very good form of 2FA (it's phishable, sometimes inconvenient, and it can become desynced), U2F is much better, but you can't encrypt a database with U2F.
KeepPass has a very customizable policy of when to lock the database. I have KeePass on my desktop set to lock if KeePass is inactive for 1 hour, or if my computer is inactive for 10 minutes, or if I lock my screen. Are you saying there should be a semi-locked state that requires a password but not a 2FA? Sure that's possible.
None of this protects you from malware on your computer though, so I don't know why we're talking about it.
I was trying imply that you need 2fa for the services itself so the passwort alone is useless.
Ironically office 365 has a nice implementation, where it for instance requires all admins to use MFA
This is my point, it is an implementation detail of the password manager to integrate OTP or another second with decryption of the vault. Any password manager can implement this.
From the perspective of the user, you are stripping a factor for some arbitrary period of time. It's a broken implementation.
I'm not sure why you are having such a hard time understanding this is an implementation detail of the password manager that can change at any time. You are treating this like it cannot be implemented differently. It absolutely can.