Additional vendor responses by Bitwarden to put the remediations and threat models into perspective:
this post was submitted on 16 Feb 2026
170 points (92.9% liked)
Technology
81286 readers
4152 users here now
This is a most excellent place for technology news and articles.
Our Rules
- Follow the lemmy.world rules.
- Only tech related news or articles.
- Be excellent to each other!
- Mod approved content bots can post up to 10 articles per day.
- Threads asking for personal tech support may be deleted.
- Politics threads may be removed.
- No memes allowed as posts, OK to post as comments.
- Only approved bots from the list below, this includes using AI responses and summaries. To ask if your bot can be added please contact a mod.
- Check for duplicates before posting, duplicates may be removed
- Accounts 7 days and younger will have their posts automatically removed.
Approved Bots
founded 2 years ago
MODERATORS
What a headline
No shit?
These password managers claim your passwords are secure, even if their servers get compromised, which is what is expected from a security standpoint. But that is apparently not the case.
You probably can't trust anything if it's compromised
Are you trying to say the front fell off?
That's not very typical
And if the client software itself is compromised then all that is meaningless.
BW06: Icon URL Item Decryption. Items can include a URL field, which is used to autofill the credentials and display an icon on the client. The client decrypts the URL and fetches the icon from the server, including in its request the domain and top-level domain of the URL. For instance, if the URL is “https://host.tld/path%E2%80%9D, the client request includes “host.tld”. This means that the adversary can learn (part of) the con- tents of URL fields. Using Attack BW05, an adversary can place the ciphertext of sensitive item fields, such as a user- name or a password, in the encrypted URL field. After fetch- ing the item, the client will then decrypt the ciphertext, confus- ing it for a URL. If the plaintext satisfies some conditions (i.e. containing a ‘.’ and no !), it will be leaked to the adversary. A URL checksum feature was deployed in July 2024, mak- ing the clients store a hash of the URL in another encrypted item field, therefore providing a rudimentary integrity check and preventing this attack. Note that old items are never up- dated to add such a checksum: this feature only protects items created after its introduction. Furthermore, URL checksums are only checked if a per-item key is present for the item. As we will see, an adversary can prevent per-item keys from being enabled with Attack BW10.
IMPACT. The adversary can recover selected target ciphertexts in the item, such as the username or the password.
REQUIREMENTS. The user opens a vault containing items that do not use per-item keys (i.e., items created before July 2024, or after Attack BW10 is run). The target plaintext must satisfy some additional conditions, detailed in Appendix
-- from the paper the article is discussing
So you could potentially expose your passwords to a compromised server or some kind of MITM. If they meet the conditions for the validation check, anyway.
My comment was to answer the question of: "Why is this relevant?" (Its been asked a lot). It's relevant because Bitwarden is claiming that they "cannot see your passwords".
I didn't think you were making the post to defend Bitwarden or something. I was just adding the details of one of the exploits the paper found that directly contradicted their claim.
Well the specific point here is that these companies claim that a server hack won't reveal your passwords since they're encrypted and decrypted on your local device so the server only sees the encrypted version. Apparently this isn't completely true.
At the point someone pulls off a valid MIM attack - which is basically a requirement here unless the whole BW/Vaultwarden server gets compromised- that is the least of someones problems. MIMs are incredibily hard these days.
Yeah, the title there really doesn't reflect the article text. It should be "you probably can't trust your password manager if the remote servers it uses are compromised".
That would be an understatement since all services claim your data is safe even in that case which is not true.
Bitwarden says all issues have already been addressed.
https://bitwarden.com/blog/security-through-transparency-eth-zurich-audits-bitwarden-cryptography/
Yes, although it sounds like they haven't finished fixing some of them:
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.
Edit: There's more information about the specific threats and remediation steps in the PDF report linked at the end of the Bitwarden blog post:
Looking through, it seems like for the most part these are very niche and/or require the user to be using SSO or enterprise recovery options and/or try to change and rotate keys or resync often. I think few people using this for personal would be interacting with that attack surface or accepting organizational invites, but it is serious for organizations (probably why they’re trying quickly to address this).
Honestly I think a server being incognito controlled and undetected in bitwardens fleet while also performing these attacks is, unlikely? Certainly less likely than passwords being stolen from individual site hacks or probably even banks. Like at that point, it would just be easier to do these types of manipulations directly on bank accounts or crypto wallets or email accounts than here, but then again, if you crack a wallet like this you get theoretically all the goodies to those too I suppose, for a possibly short time (assuming the user wasn’t using 2FA that wasn’t email based as well).
Not to mitigate these issues. They need to fix them, just trying to ascertain how severe and if individual users should have much cause for concern.
Regarding a malicious server acting under Bitwarden's fleet: As I see it, the most vulnerable target would be an organization's self-hosted Bitwarden server.
load more comments
(1 replies)
Since the summary doesn't say which three popular password managers:
As one of the most popular alternatives to Apple and Google's own password managers, which together dominate the market, the researchers found Bitwarden was most susceptible to attacks, with 12 working against the open-source product. Seven distinct attacks worked against LastPass, and six succeeded in Dashlane.
I suggest KeepassXC, I like it. Can use it with TOTP too
Keepass + Syncthing for cloudless sync between devices. Dreamteam.
Yess!
I store the keepass vault on my nextcloud
On iOS and macOS, I use Strongbox pro (one time purchase), as it integrates beautifully into the apple ecosystem using its APIs.
On linux and windows free KeepassXC with browser plug-ins
On Android I use the free keePassDX which, like strongbox, uses the android APIs for passwords
Same. My password database never touches a server I don't own and my keyfile is manually copied between my devices and stored separately from the database file.
Bitwarden. Shit.
These attacks are more around the encryption and all require a fully malicious server. It sounds like Bitwarden is taking these seriously and personally I'd still strongly prefer it to any closed source solution where there could be many more unknown but undiscovered security concerns.
Using a local solution is always most secure, but imo you should first ask yourself if you trust your own security practices and whether you have sufficient hardware redundancy to be actually better. I managed to lose the private key to some Bitcoin about a decade ago due to trying to be clever with encryption and local redundant copies.
Further, with the prevalence of 2FA even if their server was somehow fully compromised as long as you use a different authenticator app than Bitwarden you're not at major risk anyways. With how poorly the average person manages their password security this hurdle alone is likely enough to stop all but attacks targeted specifically at you as an individual.
Just adding: Passkeys do migitate a lot of these issues as well.
load more comments
(4 replies)
load more comments
(4 replies)
Keepass, upload the database file to random free cloud accounts after making changes to the database.
This is foulproof as long as the end-user device doesn't get hacked, right?
Edit: Did I say something wrong? Why downvotes? Database file are encrypted, even if someone gets it, its encrypted and they don't have your password.
So its basically safe to upload your database. If you think I'm wrong then explain why I can't use free cloud accounts to store an encrypted file?
Why would you do that? Just sync thr database with Syncthing and keep it locally on your devices. I'd never put my pw dB in a publicly available cloud online, even though it's encrypted.
For backup.
So all of my hard drives and devices are in the same house, if I was sleeping and and house caught on fire and I couldn't even get my phone in time (just a worst case example), then I lose all my passwords.
Cloud is my "offsite backup". Cuz where else would I put stuff?
Also: I though you could just safely upload encrypted files to Google Drive, why not a password database? It's just another encrypted file.
Yes and no. You can store them in a free cloud account, provided you have local copies; there's a risk your access to the cloud storage could be denied. A security risk is that they could harvest these databases, and decrypt them later.
I think your best bet, if you were to use free services, is to delete old databases from the cloud. Encrypt the new databases with the updated password manager and a new master password.
view more: next ›