Increasing the default number of PBKDF2 for existing accounts

Feature Requests Password Manager
, ,
1

The recent LastPass breach has put a lot of focus on the number of PBKDF2 hash iterations used to derive the decryption key for the password vault. LastPass got in some hot water for their default iterations setting being below the OWASP recommended setting for PBKDF2-HMAC-SHA256 of 310,000 at 100,100. However, what was more sharply criticized was the failure of LastPass to migrate older accounts to their new default, with many older accounts being left at 5,000 iterations and even reports of accounts with the iterations set to as low as 1.

Bitwarden currently has a default setting of 100,001 iterations client-side with an additional 100,000 server-side. However, I have recently read analyses from security researchers essentially claiming that the server-side hashing implementation would do nothing to protect against a password vault server breach similar to the recent LastPass attack. This means that as a defense against such an attack, there are only 100,001 iterations being used in practice. I will link the sources for this claim below with the note that I am not a security expert and am relying on the claims of those who are. If they are wrong, I would be happy to be corrected:

https://dchest.com/2020/05/25/improving-storage-of-password-encrypted-secrets-in-end-to-end-encrypted-apps/

While I have seen feature requests to introduce Argon2 and to introduce a secret key a la 1Password, I imagine these suggestions would take quite a while to implement. A simpler short-term solution would be to simply increase the default number of PBKDF2 iterations for all accounts. While of course individual users can increase this setting manually in their account settings, in practice most users won’t do this, especially ones not familiar with good security practices who are most likely to have weak master passwords and need the increased PBKDF2 iterations most.

A Mastodon post from Bitwarden has indicated that they plan on raising the default number of iterations to 350,000, which is great! However, they give no indication on the timeline for this change and are vague about whether existing accounts will automatically be upgraded to the new, higher default. Having this update apply to all accounts in critical in my opinion. I would be interested to know if there is a method for doing this and if not, will there be some kind of communication prompting users to increase this setting manually?

While on the topic, it might be worth mentioning that the minimum allowed number of PBKDF2 iteration is 5,000, which is apparently quite low. I don’t see a great need to change this as long as the default number is high enough, especially since there might be some edge cases where older hardware can’t handle a higher number of iterations. However, a warning when a user tries to set the number of iterations below the default would probably be wise.

I’m a happy, long-time Bitwarden Premium customer though I just made this forum account today. If some kind of feature request should be opened reflecting what I’ve written here, please let me know! I did not see anything from the brief search I did.

Edit: A mod has moved this to feature requests

4 Likes
2

I changed this into a Feature Request, and modified one word in the title (“all” → “existing”).

As far as the claims by Palant, his main claim (that only the client-side iterations matter) is largely valid, although he does not offer any details on how an attacker would “check whether [the derived encryption key] can decrypt the data”. His blog article also includes several gratuitous complaints, such as the fantastical speculation that an attacker who has successfully compromised Bitwarden’s production servers and tampered with the codebase (in a way that eludes standard QA checks such as automated scans and manual code reviews) would then use this power only for the purpose of decreasing the number of KDF iterations performed by the downloaded clients.

A much more detailed (and level-headed) analysis of the issue, including a proposed design fix, was published by Dmitry Chestnykh in an article that I posted about here:

2 Likes
3

Thanks for the reply. I actually did include Chestnykh’s article in my post as well, though it kind of got swallowed up by Palant’s in the output :sweat_smile:

4

The default for newly created accounts already has been raised to 350000 a few days ago:

Also about argon2 support: This is not a just feature request anymore but a work-in-progress PR. Mobile support is pretty much done, and server client PR’s are close:

Edit: I guess this doesn’t apply to existing users, so is your feature request auto migration that would, f.e prompt the user on sign in, and ask whether the KDFIterations should be updated?

3 Likes
5

I wasn’t aware that the default for new accounts had already been changed. Good news!

And yes. The feature request is essentially for existing accounts to migrated to the new, more secure default. I know the post is a bit rambling, it was originally not a feature request, but then got migrated to one.

Also, great to know that Argon2 support has made so much progress! Many thanks to all the devs working on it.

1 Like
6

Yes, this article wasn’t meant to go into too many technical details. How one would check depends on whether Bitwarden uses a MAC scheme for encrypting the protected symmetric key. If it does – that’s how. If not – AES-CBC adds a padding to the ciphertext. So wrong keys will usually result in invalid padding. And even where the padding happens to be incidentally valid, decrypting the actual data should immediately prove whether the key is correct.

The client does not know how many KDF iterations an account is configured with. It makes a prelogin call to the server and accepts any response as long as it is 5,000 or more. Meaning that a compromised server can give the client 5000 in the response and receive a weakly protected master password hash in the next API call.

7

It seems that this decision is connected to the Latest OWASP recommendation, but when I checked it a while ago, it seems that they are recommending 600,000 iterations when used with HMAC-SHA256. So, has their suggestion been changed recently or is there something that I don’t understand?

2 Likes
8

@palant Thanks for joining us on this forum.

My point was that someone with the capability to compromise the server in this way would be more likely to wreak havoc by introducing a software update containing a malicious payload, rather than setting up an exploit that would at best shave 5-9 bits of entropy off the master password.

9

So what should existing users do now? Should we manually set kdf iterations to 350,000?

1 Like
10

@PossibleGhost – Nice find. This is apparently a very recent change. As late as January 14, 2023, their “cheat sheet” webpage still showed a recommendation of 310,000.

4 Likes
11

Huh, they must have changed it in the past few days. The latest wayback machine snapshot still lists 310k.

3 Likes
12

Presumably, Bitwarden uses separate infrastructure for the API backend and update distribution. Someone who compromised one doesn’t necessarily control the other. And: no, compromise doesn’t necessarily happen through the usual deployment channels.

I’m pretty sure that I checked this page today before posting and it still said 310,000. Very recent change indeed.

13

Commented on the mobile PR for default iteration count, and Kyle found this commit

So it was just 1 hour ago.

7 Likes
14

You have 3 options:

  1. if you want to follow the OWASP guidelines, raise your client-side KDF iterations to 600,000 or more.

  2. Do nothing, and accept the fact that the effect of staying with the default 100,000 iterations (as opposed to 600,000) is equivalent to shaving 2.6 bits of entropy off the strength of your master password.

  3. Make up the difference by adding a a random numerical digit to the end of one of your passphrase word (which adds 3-6 bits of entropy), by randomly selecting a special character to use as a word separator (whihc adds 5 bits of entropy), and/or by adding one more random word to your passphrase (which adds 13 bits of entropy).

2 Likes
15

Thanks for sharing the link to the OWASP commit. Reading the annotations and following the links, one gets to the original source of these recommendations (Steve Thomas’s Tobtu.com site), including an explanation of the methodology/rationale:

https://tobtu.com/minimum-password-settings/

There we learn that the recommended values are the minimum number of iterations required to keep the hash rate at <10kH/s/GPU for a GPU that costs around $900 (e.g., 2/3 of an RTX 4090).

Steve clarifies in a Mastodon post that these are his recommended minimums for authentication, but that for encryption, one should aim to reduce the effective hash rate by an order of magnitude, to <1 kH/s.

Since the stretched master key is used to encrypt the account encryption key, achieving the hash rate recommended by Steve would require 6,000,000 client-side iterations of PBKDF2-HMAC-SHA256. Unfortunately, Bitwarden has set 2,000,000 iterations as an upper limit. Perhaps is is time to revisit Issue #589, or perhaps we should be patient and wait for your work on Argon2 support to be completed and merged. :rocket:

3 Likes
16

Yeah, as the post you linked mentioned:

Hashing algorithms are ordered best to worst. When in doubt “just use bcrypt”. Only use PBKDF2 if you must use it. PBKDF2 is a bad algorithm because it is slow for the defender and fast for the attacker.

The marginal increase in security just makes the user experience so much worse :frowning:
So for me, argon2 is the only path forward, as it is orders of magnitude slower to crack, with the same user experience.

3 Likes
17

One commenter in the article by @palant mentioned that his old account (allegedly created in 2020) was set to 5000.

I can confirm this behavior. My account was created in September of 2018. I checked my settings on Jan 12, 2023 and found my account also only had 5000 iterations.

I just want to point out that while this thread discusses whether 310,000 or 600,000 there are probably thousands of accounts with 5,000 which should be highlighted.

EDIT: Another report of a 5000 iterations account can be found here Oof, my Bitwarden account was created a while ago and was set to only 5,000 iter... | Hacker News

5 Likes
18

I run a self-hosted instance. How does this also affect me? The very same way?
Should I upgrade to get the count increase? Any other action?

19

That this happened with an account created in 2020 is hard to believe considering it was updated to 100k in October 2018: default iterations when registering is now 100k ¡ bitwarden/clients@c3a2d3a ¡ GitHub

But yeah, notify of outdated iteration count on login would be cool.

2 Likes
20

Yes, I don’t think so either. The commenter actually said that they started using the account in 2020, but the account itself is probably older.

If I read the change history correctly, there were multiple intermediate steps adjusting the iteration count for new accounts from 5,000 to 100,000 between April and September 2018. There have already been reports of accounts configured with 50,000 iterations which is one such intermediate step. But any accounts created before 2018 are likely configured with merely 5,000 iterations – there was no automated upgrade, most people aren’t even aware of this setting.