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.
The only reason my Keepass database changes is because I make new accounts on sites every now and then, and that's a fairly rare thing these days. And if I get so ungodly unlucky that my house burns down before my off-site database is updated to have that new account listed, I'll still have access to the email that account is associated with, so I can still recover the account either way.
Keeping an offsite database in sync is tedious, especially if it's delivered via sneakernet.
The off-site solution I have updates a lot more often than that, although that's only because only the really important stuff is backed up in that way; the stuff I truly need to survive my house burning down.
I'm almost done with that aspect of my life now, but every school year it feels like there's a new slate of apps, parent communication portals, etc. I need to manage these as well.
It's way more often than twice a year for me. And it's accelerating.
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!
Unrelated note: this was the first time I've linked to my static generated docs for this project and it was really fun watching the grafana dash of my fly.io nginx proxy pick up all the scraping traffic. Thanks for warming my cache :) I work with this tech all the time at my day job but this is the first time I've hosted something from my home, it's genuinely made my afternoon to see it light up.
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.
The main issue with these managers. I use an encrypted text file and Emacs, nothing on the cloud for me.
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 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.
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/
Second: The provider can get the passwords with a simple server change.
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.
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.
"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...
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
mjamil•1h ago
rorylawless•1h ago
herczegzsolt•1h ago
> 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?
tempay•1h ago
kenniskrag•1h ago
> 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
loeg•1h ago