Just to clarify the title. It was not a deliberate backdoor on the part of Passwordstate. It was a supply chain attack. There is some history to their security holes (most of the known ones being patched).
Password managers seem to be the most critical software where open source and reproducible builds are needed. Are there any good FOSS password managers that can do remote sync and team permissions?
Bitwarden seems to tick the boxes you need - FOSS license, syncs via an (open source) server which you can host yourself, or use their hosted version, and there's team versions available.
It's pretty good. There's also bitwarden_rs (a rust-based server component) if you fancy a simpler self-hosting stack that doesn't require SQL server.
The solution has been audited, I believe, but audits are only valid at individual points in time. The only downside for me is the use of electron and web technologies in many of the clients - that for me is a huge attack surface of complexity that few people can fully understand and manage.
Any idea why Bitwarden insist on their installation ID generation for self hosted deployments? it strikes me as unusual, as it's not documented WHY it's necessary, or what the ID is used for, only that you're required to give Bitwarden your email address to get the necessary ID.
If they would remove this step, or at the very least explain it, I'd be more likely to deploy and use it. Critical things like password managers should be self hosted where possible, IMO, and this is a blocker preventing trivial deployments.
As far as I remember, it was used to pass API requests for third party services (like APNS) through the main Bitwarden servers so Bitwarden's secret keys for these services weren't published, but self-hosters wouldn't have to register and manage their own accounts for these services, which can be complicated and expensive (To get access to APNS you have to pay the $100/yr apple developer subscription and you can only use it for your own apps, so you would have to build and distribute, via the app store or testflight, your own build of the app.
Bitwarden says they are hashed and encrypted with your email and master key before leaving your device so it is not possible to get them even if they are ever hacked.
So far so good, but how do they protect from hacking or from Bitwarden employees the shared secrets in an organization? I understand that each member of the organization team has their own master key.
> Bitwarden says they are hashed and encrypted with your email and master key before leaving your device so it is not possible to get them even if they are ever hacked.
This part makes electron apps even a bigger problem, because if hacker owns the app that's the point where they can grab the password before it's encrypted.
> Are there any good FOSS password managers that can do remote sync and team permissions?
Depending on what remote sync and team permissions looks like at your end, you could perhaps get there with KeePassXC [0] (password manager) and a separate sync tool (that did your sync and, effectively, your permissions management) such as Keybase KBFS [1] or SyncThing [2].
Syncing software could perhaps do so cyphertext malleability attacks. Changing the ciphertext, and deducing information on the plaintext based on client behavior.
Perhaps they could force you into a password reset for a specific site by corrupting the correct files. That might be an interesting first step for an account takeover.
These are highly complicated, active attacks. I wouldn't worry as long as your sync service isn't literally the Russian or Chinese government.
> Perhaps they could force you into a password reset for a specific site by corrupting the correct files. That might be an interesting first step for an account takeover.
It would be interesting to see that accomplished without making it obvious (particularly: without corrupting large parts of or the entire database). KeePass encrypts the whole database.
That really depends on your threat model. Every effort to reduce your attack surface increases the effort needed for your adveraries. Your "won't help very much" is only true for the trusting trust problems in the paper, i.e. if you need to survive state sponsored attacks
Trusting Trust actually says that vetted source isn't enough! Fortunately it's been defeated (https://dwheeler.com/trusting-trust/), such that vetted source and multiple compiler executables that are unlikely to be compromised in the same way can be enough if you use them carefully (which, to my knowledge, we don't).
https://twitter.com/juanandres_gs/status/1385689464329187329
https://github.com/NorthwaveSecurity/passwordstate-decryptor...
A potential issue in the password management space is that Francisco Partners (owner of NSO Group) owns Lastpass (and LogMeIn).
https://en.wikipedia.org/wiki/NSO_Group
https://www.globenewswire.com/news-release/2020/08/31/208621...
Note: I work in the IAM and PAM space and designed dashboards for saas pass.