That's not very typical

Well if you decrypt the blob on the server they can see it.

That would be an understatement since all services claim your data is safe even in that case which is not true.

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.

And if the client software itself is compromised then all that is meaningless.

No. Because the very nature of passwords and password managers make you immeasurably safer than not using one at all. Password managers in almost all markets detect password compromises and alert you to change them. Doing so is trivial and as long as you catch it in time, you're much safer and harder to target than almost any other user.

Passwords are like physical locks. Its not about being unpickable or indestructible. Its mostly about raising the barrier of entry high enough that you are an unappealing target. Why would I spend days/weeks/months trying to crack the account of someone using a random string of 14 characters unique to every service and that can change their password within hours or days--when I could instead gain remote access to hundreds of other users that keep a 'passwords.doc' file in ~/documents with open permissions? They likely use passwords like 'Snoopdog2004$' so they're easy to brute force, they won't notice incursions, and can't easily change passwords that are shared between multiple services.

I don't have the self hosting maturity to share my db across my devices yet. I need to get on that.

I don't think it should be disappointing. Bitwarden welcomes third party security testing, especially given it is open source. The tests done were just tests, and the issues were already fixed.

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.

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.

i use keepassxc for the offline database part, and syncthing to sync it (among other things) between all my devices

I was enjoying 1Password until they went completely subscription, so I switched to Strongbox (based on Keepass) and it's been pretty good. DB stored locally and I use my own tools to sync that vault to my other devices.

I use passwordsafe, no issues there

But currently all my passwords are in password store. Looking into alternatives. I like the idea of keepass because it's still local. But I also pay for proton, so might use theirs. They weren't susceptible in the recent attacks

Built on rust you say???

I got it from my system package manager. I didn't download it from the web or anything. Sudo apt-get install keepassxc. I also use keepassDX on my phone, pulled from the fdroid repository.

So just get it from your repo.

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.