The article is nearly useless for users of the software who want to know how their data may have been affected. The researchers' website is more descriptive, especilly wrt specific findings.
That's much better, thanks. According to the Bitwarden blog post: https://bitwarden.com/blog/security-through-transparency-eth... which contains its full cryptography report at the end, all the issues have been fixed except a few which are considered part of the design (see below), so if I understand correctly you have nothing to worry about if you don't use organizations and use a strong password.
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
"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."
For clarity, one of the "Accepted" vulnerabilities is that attackers who control the Bitwarden servers can set the PBKDF iteration count to "1". They set the severity of this to "low".
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".
No matter how compromised a server gets, ideally the client should never be able to provide it unencrypted data, or data is encrypted in a way such that the server can decrypt it. It is unclear if Bitwarden has fixed this core issue or not.
I mostly agree! However, I plan on posting an article on HN soon discussing some of the issues with the .kdbx file format that KeePass and derivatives use within the next couple of days. KeePass has such great potential, but falls short compared to some of its (local) competitors.
I don’t recommend any of them. Some of them have critical metadata leakage issues (Pass and derivatives, which leak the number of accounts & their names) and most others are not open source—an immediate disqualification for a local password manager. KeePassXC is my choice on desktop. Keepassium on iOS.
I recently orchestrated this, although in my case I've chosen to use 1password's cloud based store as my primary secret store, so I'm accepting some exposure right off the bat that you might not be comfortable with.
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.
Thanks, it's also available via my 1password cloud account, so it'd have to be a joint fire at my home and the 1password data center (and my phone, for that matter). Pretty bad day I feel.
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.
Well, the same issue exists for your BitWarden recovery keys or 2fa method. You need to have proper and redundant off site backups for anything valuable.
How often do your change your passwords? Assuming they are decently long and all that, why would you change them at all other than when a site gets breached?
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.
Every time I add an account, for one. And there's still plenty of (dumb) sites which force me to change my password and sometimes username periodically.
Keeping an offsite database in sync is tedious, especially if it's delivered via sneakernet.
I add an account to that database maybe twice a year, probably less. Do you make a lot more accounts than that?
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.
Fair enough, but it’s genuinely super easy to have a regular copy of your password manager saved in the cloud. You can also have a less frequently updated version stored somewhere physical that isn’t your house. My house burning down has never been a concern for me, as I’ve taken the proper precautions for my data.
I sync the database to my phone, and a couple of other devices too with syncthing. I need it on my phone anyway to log into accounts while I'm out and about.
What clients are you using ? Trying syncthing with synctrayzor with my windows boxes and Synctrain on my iPhone and it’s mostly alright but still a little spotty.
I'm also using Synctrayzor on my Windows 10 machine. I'm on Android using the official Syncthing app there as well as on Linux. It sometimes takes a while for them to discover each other, and it of course works better when all the devices are on my home network. The only real problem I've encountered is when filenames have special characters another OS doesn't like.
One of the things the article touches on is encouraging these vendors to migrate their customers to more secure/modern security standards. How is this handled with KeePass with it being, by its very nature, decoupled?
Not the parent, but a heavy user of Keepass. When you unlock your database, you can re-key it with several options for encryption algorithm, key derivation, and the transform rounds. I also have it set up with my Yubikeys as a kinda-sorta two factor for an added layer of security.
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.
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.
Haha this was a powermove. It is genuinely great that since it’s just a file you can host it anywhere you want. S3, WebDAV, your own site. I personally use copyparty and WireGuard for my kdbx file. I find it better than syncthing because there’s an obvious master copy (edited in place), and there’s no good way to keep syncthing running all the time on iOS, which can lead to sync conflicts.
Hello. I use copyparty on my LAN hosting the kdbx file. It is exposed via webdav for my phone's client (keepassium). It is always available for KeePassXC (you can use rclone or just webdav in the file explorer). This is backed up to b2 every hour. I use WireGuard to access the LAN when I am not home. My phone autoconnects to WireGuard as soon as it is on any network that is not my home network.
I sometimes casually include tokens in my comments (changing a few characters here and there) to make people gasp but parent is taking it to a different level.
caveat not properly addressed in the blog post: all "attacks" are assuming full takeover of web servers, which is certainly a scenario that should be protected against, but isn't really a vulnerability unless chained with something else.
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
No, the whole point of these systems is that you can trust them even if their servers are compromised. If you exclude that possibility from your threat model, you might as well not bother encrypting at all; just send your passwords to the server in an HTTPS POST.
I use Bitwarden, and I like them, but I still disagree.
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.
> Much like the other products we analyse, 1Password lacks
authentication of public keys. This trivially enables sharing
attacks similar to BW09, LP07 and DL02, something that the
1Password whitepaper...
> 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...
I am bit disappointed they did not immediately jump on implementing the two straightforward recommendations:
> 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?
The reddit link mentions that they only reported what is now issue #9 and bitwarden has said it's working as intended, so that's why they were "ignored" 4 years ago.
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.
At least a KeePass file via Cloud Storage seems like a somewhat sane tradeoff between security and convenience.
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.
> What you're proposing where you're adding a backdoor to your home network (via Wireguard) that needs to be maintained/hardened
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.
You can use your KeePass off of a mobile device like a thumb drive. I have my USB stick attached to my keys (house, bike etc.) which allows me to access my passwords from everywhere. Cloud based is always a risk.
We will see when the attacks are public, a lot of the malicious server attacks we have seen in the past were kinda of overblown. Not discounting OP but it is very easy to get into clickbait territory.
the threat model that actually matters for most users isn't 'malicious server' -- it's 'LastPass gets breached and attacker gets an encrypted vault dump.' the research is interesting but the real-world risk for cloud password managers is much more basic: the offline derivation attack when you have the encrypted blob. that's what happened in the 2022 breach.
I only want to know if BW01-05, 07, 10-12 and have been addressed. 06 is very minor and known, and 08-09 only appear to apply to organization accounts.
That doesn’t fit all use cases though. For example, how to fill passwords in mobile apps on the go, or how to share a subset of your passwords with your family (including syncing password changes with them).
> 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.
Why does the federal reserve keep all that gold in one place? It’s far better to have a ridiculously secure store than it is to have to reuse passwords across a hundred sites (nobody here can remember a hundred unique high entropy passwords). I trust the cryptography far more than my brain to handle these things.
It doesn’t perfectly map, but it gets a visual point across. I cannot be convinced that it’s better for the average person to maintain a couple permutations of a primary password for a hundred different sites than it is for them to store it in a vetted and audited password manager. Even with the vulnerabilities mentioned in the paper you are far better off with a password manager and thus 100 fully unique passwords then without.
The article is nearly useless for users of the software who want to know how their data may have been affected. The researchers' website is more descriptive, especilly wrt specific findings.
https://zkae.io/
That's much better, thanks. According to the Bitwarden blog post: https://bitwarden.com/blog/security-through-transparency-eth... which contains its full cryptography report at the end, all the issues have been fixed except a few which are considered part of the design (see below), so if I understand correctly you have nothing to worry about if you don't use organizations and use a strong password.
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
> KDF settings are stored on the server without authentication, allowing a malicious server to reduce the iteration count
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?
Bitwarden's response [1] is interesting.
"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...
For clarity, one of the "Accepted" vulnerabilities is that attackers who control the Bitwarden servers can set the PBKDF iteration count to "1". They set the severity of this to "low".
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".
you can see them in the report at the bottom, but I counted four. See my post above.
No matter how compromised a server gets, ideally the client should never be able to provide it unencrypted data, or data is encrypted in a way such that the server can decrypt it. It is unclear if Bitwarden has fixed this core issue or not.
1Password comes out looking relatively good here.
That's why KeePass is still the king. Offline vault > online vault.
I mostly agree! However, I plan on posting an article on HN soon discussing some of the issues with the .kdbx file format that KeePass and derivatives use within the next couple of days. KeePass has such great potential, but falls short compared to some of its (local) competitors.
Which local competitors do you recommend? Is a text file one of them?
I don’t recommend any of them. Some of them have critical metadata leakage issues (Pass and derivatives, which leak the number of accounts & their names) and most others are not open source—an immediate disqualification for a local password manager. KeePassXC is my choice on desktop. Keepassium on iOS.
Looking forward to
What to do if my house catches on fire, including my computer where the passwords are stored?
I recently orchestrated this, although in my case I've chosen to use 1password's cloud based store as my primary secret store, so I'm accepting some exposure right off the bat that you might not be comfortable with.
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!
Just a heads up, Fireproof Safes are not failure proof, you should have that key securely stored somewhere else as well.
Thanks, it's also available via my 1password cloud account, so it'd have to be a joint fire at my home and the 1password data center (and my phone, for that matter). Pretty bad day I feel.
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.
It’s just an encrypted file on disk. You’d depend on whatever backup solution you already have in place.
Well, the same issue exists for your BitWarden recovery keys or 2fa method. You need to have proper and redundant off site backups for anything valuable.
Not exactly. I need to have those offsite, but they are not modified at the same frequency as passwords.
How often do your change your passwords? Assuming they are decently long and all that, why would you change them at all other than when a site gets breached?
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.
Every time I add an account, for one. And there's still plenty of (dumb) sites which force me to change my password and sometimes username periodically.
Keeping an offsite database in sync is tedious, especially if it's delivered via sneakernet.
I add an account to that database maybe twice a year, probably less. Do you make a lot more accounts than that?
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 take it that you don't have children?
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 don't, and now I have yet another reason not to.
Fair enough, but it’s genuinely super easy to have a regular copy of your password manager saved in the cloud. You can also have a less frequently updated version stored somewhere physical that isn’t your house. My house burning down has never been a concern for me, as I’ve taken the proper precautions for my data.
I sync the database to my phone, and a couple of other devices too with syncthing. I need it on my phone anyway to log into accounts while I'm out and about.
What clients are you using ? Trying syncthing with synctrayzor with my windows boxes and Synctrain on my iPhone and it’s mostly alright but still a little spotty.
I'm also using Synctrayzor on my Windows 10 machine. I'm on Android using the official Syncthing app there as well as on Linux. It sometimes takes a while for them to discover each other, and it of course works better when all the devices are on my home network. The only real problem I've encountered is when filenames have special characters another OS doesn't like.
Off-site backup.
One of the things the article touches on is encouraging these vendors to migrate their customers to more secure/modern security standards. How is this handled with KeePass with it being, by its very nature, decoupled?
Not the parent, but a heavy user of Keepass. When you unlock your database, you can re-key it with several options for encryption algorithm, key derivation, and the transform rounds. I also have it set up with my Yubikeys as a kinda-sorta two factor for an added layer of security.
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.
KeePassXC can even still be online, too; example: https://logandark.net/passwords.kdbx
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.
Haha this was a powermove. It is genuinely great that since it’s just a file you can host it anywhere you want. S3, WebDAV, your own site. I personally use copyparty and WireGuard for my kdbx file. I find it better than syncthing because there’s an obvious master copy (edited in place), and there’s no good way to keep syncthing running all the time on iOS, which can lead to sync conflicts.
Just how do you use copyparty and wireguard for this if you kindly elaborate on that please
Hello. I use copyparty on my LAN hosting the kdbx file. It is exposed via webdav for my phone's client (keepassium). It is always available for KeePassXC (you can use rclone or just webdav in the file explorer). This is backed up to b2 every hour. I use WireGuard to access the LAN when I am not home. My phone autoconnects to WireGuard as soon as it is on any network that is not my home network.
I sometimes casually include tokens in my comments (changing a few characters here and there) to make people gasp but parent is taking it to a different level.
caveat not properly addressed in the blog post: all "attacks" are assuming full takeover of web servers, which is certainly a scenario that should be protected against, but isn't really a vulnerability unless chained with something else.
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/
No, the whole point of these systems is that you can trust them even if their servers are compromised. If you exclude that possibility from your threat model, you might as well not bother encrypting at all; just send your passwords to the server in an HTTPS POST.
I use Bitwarden, and I like them, but I still disagree.
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.
Does't TLS pinning alleviate the DNS attack?
Not if the advertise zero knowledge encryption. As far as I understand the password sharing / collaboration feature is often the problem.
Second: The provider can get the passwords with a simple server change.
Has there been a similar evaluation of 1Password?
> Much like the other products we analyse, 1Password lacks authentication of public keys. This trivially enables sharing attacks similar to BW09, LP07 and DL02, something that the 1Password whitepaper...
> 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
1Password wrote a response to the paper: https://1password.com/blog/eth-zurich-zero-knowledge-malicio...
I am bit disappointed they did not immediately jump on implementing the two straightforward recommendations:
> 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?
It seems like 1Password is significantly more secure given the ratio of its market share to the number of articles I’ve seen like this one.
See https://zkae.io/
Someone on Reddit says they reported some of those Bitwarden issues to them 4 years ago and they were ignored: https://www.reddit.com/r/Bitwarden/s/LsJWCaQ6YD
The reddit link mentions that they only reported what is now issue #9 and bitwarden has said it's working as intended, so that's why they were "ignored" 4 years ago.
KeePass ftw
Just make sure you have backups
Online password managers is the distinction here.
> cloud-based password managers.
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.
Hard agree, but Average Joes have no idea what any of those words mean let alone the means to do it.
At least a KeePass file via Cloud Storage seems like a somewhat sane tradeoff between security and convenience.
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.
> What you're proposing where you're adding a backdoor to your home network (via Wireguard) that needs to be maintained/hardened
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.
You can use your KeePass off of a mobile device like a thumb drive. I have my USB stick attached to my keys (house, bike etc.) which allows me to access my passwords from everywhere. Cloud based is always a risk.
It’s more likely that I’ll drop my phone into a river than that Bitwarden will get compromised.
We will see when the attacks are public, a lot of the malicious server attacks we have seen in the past were kinda of overblown. Not discounting OP but it is very easy to get into clickbait territory.
I’m not sure why anybody is surprised. Eventually, everything is proven to be less secure than promised, especially once they are online.
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 threat model that actually matters for most users isn't 'malicious server' -- it's 'LastPass gets breached and attacker gets an encrypted vault dump.' the research is interesting but the real-world risk for cloud password managers is much more basic: the offline derivation attack when you have the encrypted blob. that's what happened in the 2022 breach.
I only want to know if BW01-05, 07, 10-12 and have been addressed. 06 is very minor and known, and 08-09 only appear to apply to organization accounts.
>cloud-based password managers
The main issue with these managers. I use an encrypted text file and Emacs, nothing on the cloud for me.
That doesn’t fit all use cases though. For example, how to fill passwords in mobile apps on the go, or how to share a subset of your passwords with your family (including syncing password changes with them).
"Why do people need this tool? I use a much more rudimentary solution that doesn't do half the things a password manager does"
Save you the click.
The researchers demonstrated 12 attacks on Bitwarden, 7 on LastPass and 6 on Dashlane
a better summary from the site:
> 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.
What a sane idea to store all your secrets in one place.... for attackers to get ahold of them in one move.
Why does the federal reserve keep all that gold in one place? It’s far better to have a ridiculously secure store than it is to have to reuse passwords across a hundred sites (nobody here can remember a hundred unique high entropy passwords). I trust the cryptography far more than my brain to handle these things.
Your argument is flawed. And you know it. For a starter, one gold bar there is around 12.5 kgs.
It doesn’t perfectly map, but it gets a visual point across. I cannot be convinced that it’s better for the average person to maintain a couple permutations of a primary password for a hundred different sites than it is for them to store it in a vetted and audited password manager. Even with the vulnerabilities mentioned in the paper you are far better off with a password manager and thus 100 fully unique passwords then without.
Educate us how then many unique secrets "should" be managed.
Not in one "basket".