One of the Hacker News commenters suggestions which sounds reasonable is to upgrade the user to the current default KDF iterations upon a change of the master password. This operation logs the user out of all accounts in any event so it should be relatively low friction to update the KDF iterations simultaneously. The user probably wouldn’t even notice. I don’t think this replaces an automatic migration or at least global notifications for iterations set below the default, but it is still a good suggestion.
2 Likes
I had an old, thankfully empty LP account running with 5000 iterations. This is a fairly obscure setting and should be updated for existing accounts transparently to avoid the same situation.
Also, if/when Argon2 etc gets implemented all accounts should be updated to reflect that too.
Not sure if treating this as a feature request is sufficient, since it’s already making circles in various cybersecurity circles.
Here’s an article I’ve come across on reddit criticizing bitwarden for not taking action on existing accounts: Bitwarden design flaw: Server side iterations | Almost Secure
It should be noted that that article is the same one I initially cited. Wladimir Palant seems to be the only security researcher really sounding the alarm here, but I haven’t seen anyone disagree substantively with his findings. My understanding is that a strong master password should still be secure even with a low number of KDF iterations, but for a product like a password manager, the bar should probably be higher than that.
2 Likes
Thanks for the feedback all, the team is updating the default and exploring solutions for existing accounts 
6 Likes
I think this is a bigger concern for a reason I have not seen discussed yet. The hash credential to login to Bitwarden servers is only 1 PBKDF2 iteration from the vault master key. Therefore, a rogue server could send a reply for any number of client iterations and get a result that always is 1 PBKDF2 away from the master key. I would think this could easily be brute forced. I would probably think a rogue server (pretending to be a real Bitwarden server) would actually want to request the most likely value that an account has used- 100,000. Then the rogue server could test this credential against a real Bitwarden server and see if it works. If it does work, then the vault can be downloaded and the process of brute forcing 1 PBKDF2 iterations begins to try to find a match for the login hash provided.
Alternatively, if a hacker gets access to a Bitwarden server or is able to do a MITM attack to capture network traffic and the login hash that a real Bitwarden client sends to a real server, then this valid login hash can also be brute forced with 1 PBKDF2 to determine the user’s vault master key.
Am I wrong in this assessment? I am looking at page 10 of the whitepaper and see clearly a 1 PBKDF2 iteration performed on the master key with the master password as salt to generate the login password hash.
1 Like
Palant’s article, while highlighting a problem that was already known, is unnecessarily sensationalistic and alarmist. In fact I posted about this issue a month ago, and no one batted an eye. And now, all of a sudden, there is full-blown panic.
Although the issue exists and should be addressed for added security, it is a tempest in a teacup. The difference between 100,000 and 200,000 iterations is the equivalent of 1 bit of entropy in your password. Even the few early adopters who may have had their iteration count set at 5000 should have little reason to panic; in their case, the equivalent entropy difference is only 5 bits, equivalent to removing a single character from an all-lowercase password. If your password is so weak that this change would make the difference between your vault being crackable or not, well, then you probably have bigger problems.
The master key is 256 bits of high entropy. Even at just 1 iteration, that’s not feasible to brute-force. The point of the PBKDFs in general is to make low entropy credentials (human chosen passwords) harder to brute-force by requiring more work. If the credentials are high entropy (the master key), this doesn’t apply.
2 Likes
Thanks @Quexten I think I understand. Also there are two (hopefully) unknown values with the master key as the payload and the master password as the salt, making a 1 PBKDF2 iteration brute force very difficult? You need to try combinations of both the key and salt?
So then isn’t 1Password’s use of a large salt key as input with a user’s password to derive the vault key far superior the Bitwarden’s use of a likely unknown master password with a likely KNOWN email address as the salt? Increasing the default client PBKDF2 iterations by 3 times (1.5 bits) seems to be nowhere near an improvement as changing over to using a random key instead as the initial salt.
Somebody else already had the same concern yesterday. I replied:
Thanks for providing some perspective on the issue. I do want to highlight an earlier post of @palant’s where he does some calculations for how cracking costs change for a 50-bit entropy password based on PBKDF2 iterations used for the hash.
Certainly increasing the strength of your master password will be more effective than upping KDF iterations, but it does seem that the latter can still make a big difference in terms of how much money it would cost to crack a password ($75,000 to $1,500,000 for 5,000 to 100,100 iterations in Palant’s example).
I didn’t check Palant’s math though. He says he bases the cost calculations off of this blog post from 1Password, but the 1Password post doesn’t make it clear (at least to me) how exactly changing the iterations affects the calculation.
Assuming his calculations are correct, the KDF iterations number does seem significant. For very weak passwords and very strong passwords it might make little difference in practice, but most passwords are somewhere in between.
OK, understood. But then can someone explain why the server side uses 100,000 iterations to hash the master password hash (to save in their database)? The MPH should be pretty random 256 bit value right, so wouldn’t it also be very hard to brute force with 1 iteration if someone gained access to the Bitwarden database and got the hashed values? So why use 100,000 here on server, and only 1 when generating the MPH on client?
A site that skips the self-promotion and instead provides an actual interactive calculator is this one:
The derivation of the widely cited 1Password cost estimate of $6 per 232 guesses (for 100k iterations of PBKDF2-SHA256) is not documented in Jeffrey Goldberg’s 2021 blog article, but it appears to be based in part on the reports submitted by the 1st place and 2nd place winners in 1Password’s 2018 cracking challenge. These reports show that the winning teams’ operating costs were $3.85 and $2.00, respectively, per 232 guesses, so I can only speculate that the $6 figure represents an adjustment to take into account capital expenses (for example, $12k spent by the winning team to acquire 21 GPUs for their rig).
To crack a 4-word passphrase (if protected only by 5000 iterations) in a realistic amount of time (say, about 4 months), an attacker would have to invest in hardware expenses including at least $150k to assemble a rig containing a hundred high-end GPUs, and then pay the operating costs for running their rig continuously for 7000 hours. For now, I’ll guesstimate those operating costs as $10k.
If you increase the iteration count to 100,000 (i.e., 20× more than 5000), this would increase the time required to crack the passphrase to almost 7 years, and increase the operating costs to $200k. The capital expenses would not be affected by the iteration count.
So if you think that an adversary with this kind of computing power and operating budget would zero in specifically on your vault for a brute-force attack, then you may want to bump up your iteration count (or better yet, increase your password entropy).
1 Like
For a voice of reason in this debate, the following lengthy Mastodon post by Jeremy Gosney is well worth a read (in its entirety):
3 Likes
Here’s my problem. I have a single-word fairly simple Bitwarden password. This is because I have to type it in by hand from memory several times every day. How do you make it easy and secure to enter a vault password that is complex and/or long?
Convenience and security are often mutually exclusive. Argon2 helps if you configure it to have very high resource consumption. Still, intentionally using a bad master password has it’s risks.
2 Likes
Generate a passphrase in Bitwarden with 5 or more words. Make up a ridiculous sentence that uses all the words in the right order. Say the sentence as you enter your password into Bitwarden.
Also, make sure you write down the password and store it in a secure location.
1 Like
Just came across this post, as by chance I was searching about the change.
The change has now been made to 600,000
Higher KDF iterations can help protect your master password from being brute forced by an attacker. We recommend a value of 600,000 or more.
With the warning of
### WARNING
Setting your KDF iterations too high could result in poor performance when logging into (and unlocking) Bitwarden on slower or older devices. We recommend that you increase the value in increments of 100,000 and then test all of your devices.
Has anyone made this change for an organisation and its users?
What perils and pitfalls did you find?
I know it is not increasing the pbkdf2 iterations, but to share my experience I upgraded from pbkdf2 to argon2 without any issue for me and the other members of my family 
1 Like
Each user needs to make this change individually in their personal vaults. There is no KDF for the organization vault. FYI, the latest Bitwarden release now posts a warning to users who have fewer than 600,000 PBKDF2 iterations, so you may find that users have already started to update their KDF settings:
FYI, the warning about poor performance that you quoted in your comment is only relevant to “slower or older devices”. Modern devices typically have no problem even with 2,000,000 iterations (the maximum possible). As long as you have access to at least one modern device, you will always be able to access the web vault from that device and lower your KDF settings again (if you find that 600,000 iterations caused the login/unlock to become too slow on some older/slower devices).
In any case, unless you are self-hosting and have been making server-side backups of your database, you should recommend to your users to back up their individual vaults (using a password-protected encrypted JSON export) before updating their KDF settings.
1 Like