[WARNING] Bitwarden design flaw: Server side iterations

nlinecomputers

nlinecomputers

Well-Known Member
Reaction score
8,565
Location
Midland TX
palant.info

Bitwarden design flaw: Server side iterations

Bitwarden is a hot candidate for a LastPass replacement. Looking into how they encrypt data, it doesn’t do things that much better however.
palant.info palant.info

TL : DR Bitwarden like Lastpass has NOT updated all clients to its stated default of 100,001 iterations nor have they changed it to the new default (only a few days ago) of 350,000 iterations. OWASP has bumped up its recommended default of 600,000. The server side additional 100,000 iterations are only for the transmitted password hash NOT the vault! Bitwarden has hinted that it will drop PBKDF2 in favor of the much better Argon2 protocol but no timeline for that has been announced.
 
Not really. You self host your own password manager - it still "does" all of the encryption and "safety" of storing the passwords... so there really is no personal skillset required, other than installing the software/docker/etc.

In my case, I don't need to "ever" worry about it being hacked, for all intents and purposes. It's in a secure docker container, on an Unraid Server that is encrypted.. behind a 'host' of hardware firewalls an IDS and a Honeypot. The Docker container is further backed up.. and the password manager will erase the entire password DB on 10 failed attempts (of which I could later restore from encrypted backup. Good luck!

HTTPS is required for the "mobile" portion and employs AES256 encryption beyond that.. but you could just turn that off, if worried (or turn on when needed.

Regardless, this is a much better, IMO, method to not put a big target on your back "1Password", "Bitwarden", "Lastpass" - for that's why they got hacked in the first place - for being huge repositories of passwords for the entire globe. I doubt someone would care near as much about "Aaron's Passwords", and hence, would be dissuaded to go through the trouble of hacking what equates to better security than said Online services.

My way can't be worse than "their way" - that's for sure.
 
HCHTech said:
Is this updated client available for manual installation (IOW, is the failure not to MAKE the updated client, or not to automatically INSTALL the updated client)?
Click to expand...
No it's a setting on the client. You can and should manually change PBKDF2 iterations to a much higher value. The issue is that Bitwarden is not force pushing a new minimum out to the clients or at least displaying a pop up warning users of the issue.
 
phaZed said:
My way can't be worse than "their way" - that's for sure.
Click to expand...
Not convinced of that. My firewall is port scanned all the time.

Encryption works. I don't think you're stack, so long as you have a good master password, is at anymore risk than LastPass vaults. The problem with ANY setup is the constant need to keep it updated and frankly having a third party occasionally check your setup with Pen testing. Worse it seems none of the default settings are strong enough on any service or on self hosted stacks. PBKDF2 has reached it's end of life and needs to be replaced.

And frankly your personal setup is in my mind a much more interesting target as someone running a private vault is much higher likely to be a tech with access to multiple clients. (Who other than techs runs their own vault?) My vault on Bitwarden is one in several hundred thousand vaults, all fully encrypted, unlike LastPass, and so I would have to have the bad luck of being both part of a major hack, and be picked first.

Perhaps I am at more risk but not by much and with a lot less personal work involved. Worth my $10 to have them do it so long as I pay attention to what is going on with the industry as you have to do with your own stack.
 
nlinecomputers said:
Not convinced of that. My firewall is port scanned all the time.

Encryption works. I don't think you're stack, so long as you have a good master password, is at anymore risk than LastPass vaults. The problem with ANY setup is the constant need to keep it updated and frankly having a third party occasionally check your setup with Pen testing. Worse it seems none of the default settings are strong enough on any service or on self hosted stacks. PBKDF2 has reached it's end of life and needs to be replaced.

And frankly your personal setup is in my mind a much more interesting target as someone running a private vault is much higher likely to be a tech with access to multiple clients. (Who other than techs runs their own vault?) My vault on Bitwarden is one in several hundred thousand vaults, all fully encrypted, unlike LastPass, and so I would have to have the bad luck of being both part of a major hack, and be picked first.

Perhaps I am at more risk but not by much and with a lot less personal work involved. Worth my $10 to have them do it so long as I pay attention to what is going on with the industry as you have to do with your own stack.
Click to expand...
You can self host and not expose it to the internet. Keep it behind a VPN. Been doing it this way for years, first with Passbolt and now with Vaultwarden.
 
If every there were a demonstration of the old adage, "The perfect is the enemy of the good," it's topics like this one.

Those who wish to self-host absolutely should, but articles like the original one referenced are, in effect, saying that the solution is not "good enough" and will drive people to even worse practices.

Using a password manager, any password manager, including LastPass even post breach, is a low risk proposition.
 
nlinecomputers said:
No it's a setting on the client. You can and should manually change PBKDF2 iterations to a much higher value. The issue is that Bitwarden is not force pushing a new minimum out to the clients or at least displaying a pop up warning users of the issue.
Click to expand...

They also don't enforce strong master passwords.

Also, it's not a design fault, it's a process fault. More over, go ahead and push that iteration count to where you think it should be...

Come back here when your phone melts trying to open your vault!
 
Sky-Knight said:
They also don't enforce strong master passwords.

Also, it's not a design fault, it's a process fault. More over, go ahead and push that iteration count to where you think it should be...

Come back here when your phone melts trying to open your vault!
Click to expand...
I set mine at 2,000,000. It only causes a slight slow down when the vault first opens. Shows you how powerful phone cpu are now and how GPU are a real threat as they can process billions.
 
nlinecomputers said:
I set mine at 2,000,000. It only causes a slight slow down when the vault first opens. Shows you how powerful phone cpu are now and how GPU are a real threat as they can process billions.
Click to expand...

That's the arms race, the iteration count will always need to be incremented. But once incremented it cannot be decremented, and Bitwarden hasn't a clue what devices are going to be using it.

My vault is accessed by Pixel 3as, they cannot handle that iteration count. My 6a would laugh at it. So I manage.

I also trust Bitwarden to protect my vault a ton more than Lastpass ever would.
 
Sky-Knight said:
I also trust Bitwarden to protect my vault a ton more than Lastpass ever would.
Click to expand...
Only because they are open source and the community is holding their feet to the fire or doing the work for them. Community outrage is what is driving the default iterations up. The coming change to Argon2 was not developed in house. Outside coders dropped it in github. Open Source for the win.
 
nlinecomputers said:
Only because they are open source and the community is holding their feet to the fire or doing the work for them. Community outrage is what is driving the default iterations up. The coming change to Argon2 was not developed in house. Outside coders dropped it in github. Open Source for the win.
Click to expand...
Yes sir! Invisible code is untrustable code. And yes I do aim this argument at Microsoft too.

The thing to bear in mind here...

The community is not always right. That number is just a number. And I have a contact I trust deeply with a Masters in Math, Masters in Computer Science and a Minor in Cryptography who works for NASA doing rocket research. The man has lightning on his brain when it comes to crap like this. And I use HIS experience to set my iteration counts.

But as a paid service? You're right Bitwarden should increase that count automatically over time because end users don't have a clue what that number should be. Heck, the guy that I just mentioned doesn't really know and he's a literal cryptography expert. But at very least an automatic annual increment of the KDF iterations is certainly a very useful thing.

Bitwarden could and should be running performance metrics on the devices accessing the vaults, and using those metrics to determine what iteration count can be tolerated and adjusting as needed over time.
 
Last edited:
Sky-Knight said:
That number is just a number
Click to expand...
No it is how much work has to perform for each guess attempt at the password. Bigger numbers mean more work and more work is more time. But when you can line up a row of GPUs that time doesn’t mean much. Unique and long master passwords are of more value than iteration counts.
 
@nlinecomputers

With very similar outcomes, virtually identical. This entire discussion veered into the "very remotely possible, but highly improbable, even in the worst case" from the "kinda-sorta reasonably possible" a very long way back. Which you knew, of course, was my point.
 
nlinecomputers said:
No it is how much work has to perform for each guess attempt at the password. Bigger numbers mean more work and more work is more time. But when you can line up a row of GPUs that time doesn’t mean much. Unique and long master passwords are of more value than iteration counts.
Click to expand...
Actually... it isn't.

The number pads the master password to create the encryption key.

Longer keys are harder to crack. This It doesn't change the amount of time a GPU has to take to try a key, it just makes the key longer so it's harder to crack to start with.

BUT, if your password is strong enough on its own, you're still dealing with centuries or longer to crack. KDF matters, but not as much as you'd think. And the person doing the cracking has to figure out what your KDF iteration count is, if they want to use a password to generate the key. So just having a number there... ANY number there, that isn't quite the same as everyone else is yet another password of sorts just by varying the entropy length.

But the point that must be underscored here is the true variable is a properly strong master password. High KDF on a weak password does you little good. And low KDF on a strong password isn't the vulnerability that the mass on Reddit claims it is. My password alone will cost centuries to break, I don't much care about KDF. As time marches on? yeah... I'll increase the KDF.

Also, it should be pointed out that Argon2 is THOUGHT to be better than PBKDF2, but it's not proven to be. Indeed in many ways one could say Argon2 is worse, because there's been vastly less research done on it.
 
Last edited:
You must log in or register to reply here.
Back
Top