Read the technical details of TOTP, at root, you and the other end are performing similar mathematical operations on a shared secret such that knowledge of a single result gives you no information about later results. The actual check is just a string compare; the result is not included in the vault decryption operations in any way. Thus, if you have root, you can just alter the Check2FA() function to return true. I'm not aware of any encryption algorithm that can include rotating 2FA data in the actual decryption process.
There's a keypass plugin that allows you to encrypt and decrypt your database with HOTP. I doubt it has much usage. It seems really inconvenient, and also potentially dangerous, because if your HOTP provider gets too far ahead of your database (you press the button too many times, or typo too many times), you permanently lose access to your data. You would want a HOTP provider that supports rewinding to avoid that problem. But I think HOTP doesn't really support rewinding very much.
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.
Indeed. That's a neat plugin, each time you lock the database, it rolls forward your HOTP key some number of rounds, then uses the results of those rounds to encrypt a piece of key material for the vault. Then, when you go to decrypt, as long as your HOTP app hasn't generated more than the number of rounds it rolled forward, it can generate the decryption key from the HOTP stream and decrypt the vault. A little fragile, but a neat implementation.
> 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.
>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.
> It seems to me like that would require a separate HOTP device for each password database 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.
>As it sits, the HOTP device is only _sometimes_ needed depending on the caching policy.
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.
And its not so much about protecting me, but to protect company interest right?