Hacker News Reader

Comment by ChrisSD | Hacker News Reader

> Even if you configure your account with 1,000,000 iterations, a compromised Bitwarden server can always tell the client to apply merely 5,000 PBKDF2 iterations to the master password before sending it to the server. The client has to rely on the server to tell it the correct value, and as long as low settings like 5,000 iterations are supported this issue will remain.

This seems like a serious flaw that completely undermines setting a custom value, no? If an attacker gets temporary control of a bitwarden server then they can get your password in a more easily crackable form no matter what you set.

View on HN

The only way around this would be to require a human to set the # of iterations independently on all client devices. Because if you change the # of iterations using your laptop, the server wouldn't be able to tell your phone that the # of iterations has changed. Instead you just wouldn't be able to log in until you ALSO manually changed that setting on your phone to match the new server configuration that you set with your laptop.

That would be pretty poor UX.

So yes, it's a flaw. But I don't see an acceptable mitigation for it, as all clients will have to be compatible with passwords for accounts that were last logged into 10 years ago when [super_low_iteration_number] was still considered an acceptable value. And the server will have to be able to tell the client "This account was last logged into 10 years ago. We're going to increase the number of iterations right after this, but just one last time, send me the password after hashing it 5,000 times."

Couldn't all clients always do a larger amount of iterations and not let that number be configurable at all?

Clients could dynamically determine a value based on performance. That way, the encyption gets more secure the better the hardware gets.

How would the server know what the hash is? So you log in with your phone and its 5,000 iterations, then you log in with your desktop and it's 500,000 iterations? Then you get an updated driver for your GPU and it fixes a performance bug and now its 550,000 iterations...how the fuck would the server know what the matching hash should be that it never got sent to it?

It sounds like the server would have to store the lowest possible hash (your phone), which defeats the purpose of the larger iterations on the desktop machine.

Couldn't the client send the number?

Yes but the server has to have something stored. If the data stored was last encrypted with a hash that has fewer iterations then the client side, then

1) the data cannot be decrypted with a hash of more iterations because the server can’t undo client side hash iterations.

2) if the encrypted data is exfiltrated it will still be as easy to crack as the iterations performed for the original encryption of the data at last login ten years ago.

No, because today you pick a number of iterations that takes some "long but reasonable" amount of time. Maybe that's 2 seconds, maybe that's 2 minutes...but it's the longest your customers will put up with waiting at login.

Then 10 years from now, CPU's will have sped up a LOT so that will only take 0.2 seconds or whatever. With normal users, you could update the # of iterations every year, but that requires a login to occur so that the "new" password hash can be sent by the client. With a user who only logs in every 10 years, you have to support the # of iterations that existed when the user last logged in.

It doesn't completely undermine it; if someone were to get a dump of the BW database, it would still make it harder to crack the stored hashes.

Reply on news.ycombinator.com