Technology

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.

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.

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.

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

Syncthing is great for syncing things like keepass dbs

KeePass features a built-in synchronization mechanism. I store my password file on google drive for ease of access on multiple devices. I set up triggers (on save, on custom button) to sync between the local copy and the cloud copy, using this guide: https://keepass.info/help/kb/trigger_examples.html#dbsync

Not a turnkey solution, but once setup it works like a charm.

I have my keepass file in a samba share on my raspberry pi running wireguard. But it's easier just using nextcloud. Anyway, the file is encrypted.