But there's actually a lot of surface attack area for those open source tools as well. If you're able to sneak into the supply chain and replace the _client_ with a modified, malicious version, you can make it send the master password AND the database to a remote server. No need to compromise the server. This is true for most commercial password managers as well: but I'd expect the security to be tighter there. No random maintainer should get access to the release page.
My idea was like this:
* Use KeepassX built from source
* Use Dropbox to sync the kdb files (always encrypted)
* Use a firewall to prevent any network connection to keepassx; this way even a compromised client cannot connect and send the data somewhere else.
* When updating KeepassX, always build from an older git commit; I assumed that in ~15-20 days if there's a fuckup on git source, it will be announced.
BUT: it was hard. Bitwarden just works better. I still build it from source on desktop computers, though, and take a look at the website before updating, just to stay sure. (And I think IOS app process will make it harder to submit malware there anyway).
>If you're able to sneak into the supply chain and replace the _client_ with a modified, malicious version, you can make it send the master password AND the database to a remote server
I've heard about this as a possibility for as long as I can remember, but while this remains a possibility, major online providers get hacked every year or so.
Major providers are more valuable targets because the potential loot is bigger.
I wonder if major providers are also more likely to detect intrusions. This is the part that concerns me about non-cloud alternatives. For example, if KeePass got compromised, how long would it take for us to learn about it?
(Although I don’t have much faith left in LastPass, and I don’t have strong reasons to think that 1Password is better since as an outsider to their operations I know just about as much about either.)
But there's actually a lot of surface attack area for those open source tools as well. If you're able to sneak into the supply chain and replace the _client_ with a modified, malicious version, you can make it send the master password AND the database to a remote server. No need to compromise the server. This is true for most commercial password managers as well: but I'd expect the security to be tighter there. No random maintainer should get access to the release page.
My idea was like this: * Use KeepassX built from source * Use Dropbox to sync the kdb files (always encrypted) * Use a firewall to prevent any network connection to keepassx; this way even a compromised client cannot connect and send the data somewhere else. * When updating KeepassX, always build from an older git commit; I assumed that in ~15-20 days if there's a fuckup on git source, it will be announced.
BUT: it was hard. Bitwarden just works better. I still build it from source on desktop computers, though, and take a look at the website before updating, just to stay sure. (And I think IOS app process will make it harder to submit malware there anyway).