Built on rust you say???

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.

That would be an understatement since all services claim your data is safe even in that case which is not 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.

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

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”, 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.

That’s not very typical

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.

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.

You could use Github or similar. Your password file itself requires a password, so as long as the passwords are different you aren’t screwed if Github is compromised.

Either that or you could keep it on your phone and type your password in manually - Keepass lets you generate passphrases which makes typing them a lot easier.

Or you could store it on your own server and VPN in if you’re allowed to. It’s all pretty flexible.

Syncthing is great for syncing things like keepass dbs

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.

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.

Just adding: Passkeys do migitate a lot of these issues as well.

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.

no, Bitwarden isn’t “based off” anything

So just get it from your repo.

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.

What’s a metaphor allegory?