cross-posted from: https://infosec.pub/post/42164102
Researchers demo weaknesses affecting some of the most popular options Academics say they found a series of flaws affecting three popular password managers, all of which claim to protect user credentials in the event that their servers are compromised.…
I’ll be honest, password managers are like the holy grail of desirable to breech. If you’re using one it will be constantly under attack. It being breeched or vulnerable shouldn’t be a surprise. There isn’t really a secure way to store large amounts of passwords that doesn’t have some vulnerability issues.
breech
breach, right?
That’s why I liked password store, no servers, just my encrypted password files on my own computer, that I sync over to my other devices.
Apparently it’s dying soon through, so I need an alternative.
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 keepassxc for the offline database part, and syncthing to sync it (among other things) between all my devices
I just write down password hints on a scrap of paper.
If you don’t have to use your passwords from multiple locations, your hints are intelligible only to you, and you don’t leave the paper anywhere too obvious, this isn’t a bad solution.
JFC this headline. BREAKING NEWS: Healthy people die off an old age.
Password managers are supposed to be designed to resist a situation where they’re compromised, and are only ever supposed to see a mysterious blob of encrypted data without ever having access to any information that would help decrypt it. The headline’s more like M1 Abrams Tanks Vulnerable to Small Arms Fire - it’d be totally expected that most things die when shot with bullets, but the point of a tank is that it doesn’t, so it’s a big deal if it does.
Things you should know: Your car won’t drive after it’s broken down.
Additional vendor responses by Bitwarden to put the remediations and threat models into perspective:
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.
Probably?
You probably can’t trust anything if it’s compromised
Are you trying to say the front fell off?
That’s not very typical
It wasn’t designed for the front to fall off, that’s for sure!
Well, what sort of standards are these tools built to?
For the front to stay on!
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.
Well if you decrypt the blob on the server they can see it.
There’s something nice about the phrase “decrypt the blob.”
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.
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.
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”.
Well if they store an encrypted blob they can’t see them.
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.
And if the client software itself is compromised then all that is meaningless.
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.
And glosses over what it claims are the two that dominate market (combined market share of 55%) which negates their headline, since it’s likely the reader is using one of those two password managers.
Next do proton pass
So I chose the worst pick, eh?
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.
Anything against keepass
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.
Ah, great, thank you! Carrying on…
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.
I don’t have the self hosting maturity to share my db across my devices yet. I need to get on that.
If it’s critical, don’t self host it. It’s not worth it.
I know people will argue; I just need something that works and that I don’t have to worry about patching.
Personal recommendation: Start with a selfhosting support software like Casa, Yuno or (my recommendation) Cloudron. Start hosting the app there with frequent backups and occasionally export into regular Bitwarden as a failsafe.
And when you are comfortable switch over to properly self hosted Vaultwarden.
With vault/bitwarden the client handles that sharing for you.
Thats really disappointing. At least the selfhosted version means it would have to be a heavily targeted attack.
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.
Yeah, after seeing their response I’m quite satisfied. They’re one of the good guys and I hope it stays that way.
Which in turn is based off of KeePass, right? So double shit?
no, Bitwarden isn’t “based off” anything
Oh my mistake. Not sure why I thought that.
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 passwordsSame. 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 know they’re convenient, but people should really stop using cloud-based password managers and start using local ones. I personally recommend KeepassXC.
deleted by creator
How do you recommend people sync between devices? What about devices that, for security reasons, do not allow flash drives or any external device to be plugged in?
Syncthing is great for syncing things like keepass dbs
Works on iOS?
There is Synctrain and Möbius Sync. They are not perfect due to iOS restrictions on apps running in the background, but they work well enough as long as I occasionally open them to make sure they sync.
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.
At that point, why bother with the setup of samba shares and nextcloud or syncthing or whatever else and not use VaultWarden with its built in sync over WireGuard/TailScale?
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.
Sadly this functionality is not included in KeepassXC, so I continue to use the original Keepass for this reason, but I agree, my setup is the same and I’m very happy with it.
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.
So, absolutely no difference in security compared to having a properly secured self-hosted VaultWarden instance. Gotcha.
In the niche situation of not being allowed to connect USB drives to the computer you’re using? I guess.
There’s nothing stopping you from keeping it on an offline device and typing them in manually.
And keepass is perfectly cloud ready by placing the kdbx file into your cloud storage and sync using webDav or similar.
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?
This is terrible advice, even if I assume you are also using a key-file on a removable usb. An attacker can brute force decrypt your db. There is no rate limiting when you literally have the database file, they could replicate it across thousands of servers each with dozens of cores, each core trying a dozen keyphrases per second. That’s assuming a motivated attacker like a government or crypto scammers, but why open yourself to that possibility?
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.
I see. For this scenario, I have another Syncthing server, which is on 24/7, responsible for offsite backups.
Ad encrypted files: true, but why expose them to a potential adversary? If there should be a flaw in the encryption (now or future) the other party already has access to the 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.
I store my passwords on a flash drive with KeepassXC. How about you compromise that server… Oh wait a minute, no server?
As long as your copy isn’t a trojan.
https://cybersecuritynews.com/hackers-weaponize-keepass-password-manager/
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.
Repos can get / have been hacked/malicious code injected.
So can anything. The article was about people getring compromised copies from malicious websites. The answer to that is to get it from a legirimate source, so if your comeback is the legirimate source can get compromised, the only answer is to not use the fucking internet. What the fuck do you want to hear?
