Comment by lrvick
2 days ago
Those are of course just minimum viable proofs of concept for users with the CLI installed because they are succinct. Real malware could of course install the CLIs for the user helpfully or just directly access the database the next time it is unlocked and dump everything just as easily. A malicious browser plugin to dump the master password to bulk decrypt works just as well.
Decrypting -all- passwords any time you decrypt -any- password under the hood is an irresponsible design for a password manager, especially on modern hardware with so so so many other options that enforce rate limiting, hardware anchored encryption, and physical user consent.
Performative 2FA for every secret like 1password does when the binary has direct access to bulk decrypt all secrets in plain text with a key in system memory is a very strange choice given you could just have the hardware doing the individual decryption for a single secret instead of exposing the secrets that can bulk decrypt the whole database.
Well, they’re not minimum-viable if they don’t work, which they won’t for most users. It’s not a simple matter of the database being unlocked or locked, as I say it’s at least a per-process authentication, protected by the 1Password daemon. I’m not saying it’s a perfect system, but exaggerated mischaracterisation, with no apparent thought to the experience of the average user, doesn’t help your argument. You don’t seem to put much value in memory protection or process sandboxing. Yes with enough exploits you can do anything, but that’s true in any case. The fact is, 1Password is good enough for most people, and even at least one bank that I’m aware of. I’m willing to be convinced of a better implementation, but the fact you’re so scathing of something that works and has UX benefits over per-secret keying is off-putting. All design is trade-offs.