Issue 5: Organisation Key Injection (Medium)
When users interact with organizations, a trust relationship is established through the exchange of cryptographic keys. A malicious server could add users to arbitrary organizations by encrypting an organization symmetric key under the user's public key and including it in sync responses. The client would silently accept the new organization membership. Alternatively, when a user creates an organization, the malicious server could substitute the newly created organization's keys with attacker-controlled keys during the post-creation sync.
Issue 7: Disable KDF Bruteforce Protection (Low)
Bitwarden uses Password-Based Key Derivation Functions (PBKDF2 or Argon2id) to derive the master key from the user's master password. The iteration count – currently defaulting to 600,000 for PBKDF2 – provides brute-force resistance. The researchers identified that KDF settings are stored on the server without authentication, allowing a malicious server to reduce the iteration count and receive a master key hash that is faster to brute-force.
Issue 9: Malleable Vault Format and Unencrypted Metadata (Low)
The researchers identified that while individual fields are encrypted, metadata about field positions and item structure is not integrity-protected, potentially allowing field reordering or item manipulation
Issue 10: Access Violation in Organisation Collections (Low)
Organization collections enable shared access to vault items among organization members. By design, the organization symmetric key is shared with all organization members, allowing them to access collection contents to which they have specifically been granted access
How though, that would also require the client to re-generate the key based on the server setting without te user choosing to do so, does it do that?
"All issues have been addressed by Bitwarden. Seven of which have been resolved or are in active remediation by the Bitwarden team. The remaining three issues have been accepted as intentional design decisions necessary for product functionality."
They don't expand on what those three are.
1. https://bitwarden.com/blog/security-through-transparency-eth...
They've also "accepted" a vulnerability --- BW01 from the paper, I believe --- that allows a malicious server to read all vault items from a user as soon as they accept any invitation (real or not) to an "organization".
It's not centralized, of course; you still have to download the entire database, and then potentially upload the entire database again for any changes; but it doesn't have these vulnerabilities.
And I was queasy of hosting mine on Dropbox.
I've documented the recovery process here: https://docs.eblu.me/how-to/operations/restore-1password-bac...
Basically, I have a borg backup job which runs every day, in a 3-2-1 replication strategy with the backups being sent both to a locally encrypted NAS (backups themselves have an additional layer of encryption via borg) as well as off-site with BorgBase. Those backups scoop up an export of 1password that I have a reminder to kick off manually about once a month via this script: https://github.com/eblume/blumeops/blob/main/mise-tasks/op-b...
The password that decrypts the key (along with the password that decrypts the backup) is stored on a piece of paper in a fireproof safe in my house. I've got a reminder to practice the entire DR process every six months, although I've only done it once so far as this is all pretty new.
It was fun to build!
To keep the encryption modern regular updates are made to the program, and any migration would happen when re-encrypting the database. Checking my earliest entry, I've used it for 15 years without a hiccup.
almost all online services would be "vulnerable" in this way - take almost any login system. an RCE on a system hosting a login page would obviously be vulnerable to account takeover
better link here (the technical details): https://zkae.io/
One of the things Bitwarden's design is MEANT to offer is "zero knowledge" meaning that it is an AES-256 encrypted database "blob", with PBKDF2 derived master password.
So "compromised" server absolutely IS something the DESIGN should protect against. If compromising Bitwarden's servers lets them extract what they say they can extract, then the whole "zero knowledge" assurance is dead in the water.
Plus, Bitwarden themselves don't even need to be compromised, we could have a DNS redirect into a server the bad-guys (inc. national-state) control. Then leverage that into complete compromise of your database.
Second: The provider can get the passwords with a simple server change.
> IMPACT. Complete compromise of vault confidentiality and integrity. The adversary can read and decrypt all vault con- tents encrypted after the attack, including passwords, credit card information, secure notes, and other sensitive data stored in the vault. Similarly, they can inject new items into the vault after the attack. REQUIREMENTS. The client fetches key material from the server, for example due to the user logging in on a new device. If executed on a non-empty vault, the attack results in the client losing access to all items already in their vault, while leaking any new items added to the vault after the attack took place. If the attack is executed at the time of vault creation, the attack is effectively undetectable by the client, since it cannot distinguish between a ciphertext it created and the ciphertext created by the server during the attack. PROPOSED MITIGATION. A straightforward mitigation is to have the client sign vault keys using the RSA private key in the keyset before encrypting them with the RSA public key. Ideally, two different key pairs would be used for...
from the paper: https://eprint.iacr.org/2026/058.pdf
> PROPOSED MITIGATION. A straightforward mitigation is to have the client sign vault keys using the RSA private key in the keyset before encrypting them with the RSA public key.
> PROPOSED MITIGATION. [...] it would be easy for 1Password to prevent it entirely: the secret key can be used (with proper key derivation) to authenticate the KDF parameters with a cryptographic MAC.
To be fair, these issues are not really impacting long-time users. I have hundreds if not thousands of items in my vaults, there's no way i'm not noticing if they dissappear (which would be a side effect of these attacks).
Overall, I think 1password can be proud of their architecture and product quality, but i'd love to see these improvements - and maybe something like a "signal verification code" for sharing?
Enough said. This kind of stuff should be offline only. If you need to access your password database on multiple devices, set up a LAN and/or a Wireguard tunnel for remote access.
What you're proposing where you're adding a backdoor to your home network (via Wireguard) that needs to be maintained/hardened, and then still needing a LAN hosting solution for the actual database running 24-hour, is neither convenient nor secure (least of all because of layer 1 / fire / theft).
This is a fragile solution which isn't solving any particular problem; but certainly introducing multiple new exciting potential problems.
I have been doing this for years, and it is both convenient and secure. No maintenance or hardening is required, as Wireguard was intentionally designed not to require any tinkering. The setup is literally one config file with the public keys of the devices allowed to access the network. I run this directly on my firewall, which happens to be an x86 PC, but you could run easily run this on a router with OpenWrt. It's hard to imagine a more secure setup than this, since you manage your own keys and no third party is involved.
Just make sure you have backups
There are certain types of data I prefer to have complete control over. Passwords, no matter how encrypted they claim to be, are top of the list.
The main issue with these managers. I use an encrypted text file and Emacs, nothing on the cloud for me.
The researchers demonstrated 12 attacks on Bitwarden, 7 on LastPass and 6 on Dashlane
> We examine the extent to which security against a fully malicious server holds true for three leading vendors who make the Zero Knowledge Encryption claim: Bitwarden, LastPass and Dashlane [...] The attacks range in severity, from integrity violations of targeted user vaults to the complete compromise of all the vaults associated with an organisation.
