Master pass stopped working after increasing KDF

Hey @ddejohn I’ve been reviewing this one with the team and it sounds like this one is unrelated to the KDF change, but for official support you can follow up at

As @bw-admin suggested, you should contact tech support to see if anything can be done, but I doubt they will be able to roll back your vault to an older version. Imagine that your master password is leaked and that you quickly change your master password to prevent anybody from accessing it using the leaked credentials. In such a scenario, it would be a security risk if there was a way for an attacker to have your vault restored to the old version (matching the master password that they are in possession of).

Addition info from the team, does this sound like the issue: [Android] When account it set to maximum 2,000,000 PBKDF iterations cannot log on · Issue #2295 · bitwarden/mobile · GitHub

Can you clarify you are/are not able to log in to the web vault?

1 Like

I changed my KDF from 100k to 300k, so nowhere near that limit, and I am unable to login to the web vault.

Can anybody maybe screenshot (if possible) the password changing process? I’m thinking I may have somehow managed to change my password, in which case I’m totally screwed. I’m wondering if I can remember what I saw the other night in the web vault (again I was going through the motions and wasn’t paying strict attention to what I was doing, so there’s a chance I walked all the way through a password change process without realizing, though I highly doubt it).

Correct, no way to see when/if I changed passwords, and no vault backups, per support.


Just before clicking Change master password:

When clicking the button, there is a brief animation of a circle of dots overlaid on the button (this may be very quick if your number of KDF iterations is low), then you are immediately kicked out to the login screen:

Note that the green box with the confirmation message remains visible only for a very short time (in fact, I had to repeat the password change process, because I was unable to grab a screenshot showing the confirmation message the first time that I did this).

An idea:

Perhaps you thought you were changing your KDF iterations, but by not paying attention, you actually changed your master password to be 300000 (or 300,000)? Try it, can’t hurt!

1 Like

Okay yeah I didn’t think I was that oblivious. Doesn’t look like I changed my password unless there’s some other UI flow. Also both 300000 and 300,000 would be invalid passwords, but thanks for the suggestion anyway.

Are there other ways to get the keyhash? As I explained in my thread, I’m not a regular Chrome user, so the keyhash I was able to extract from the log files only matched a previous password.

The key hash is included in any locally cached vault copy. All the Bitwarden apps maintain a locally cached encrypted vault as long as you are logged in. Unfortunately, in your case, all of your logged in devices had an active internet connection when you made the changes in your account security settings, so they were all logged out (which purges the locally cashed vault, erasing the stored keyHash value).

There was a (recently fixed) bug in the Chrome browser extension that resulted in the locally stored vault not being purged when the account is logged out. This is why I had suggested looking at the .log files for the Chrome extension.

I have never tested whether a similar bug exists/existed for the Firefox browser. You could try to find the cache for the Firefox browser extension (the name of the folder has the form %AppData%\Roaming\Mozilla\Firefox\Profiles\your_profile\storage\default\moz-extension+++[UUID]^userContextId=[integer], where the values of [UUID] and [integer] would be specific to your installation). Then use search to search the contents of the folder to see if any file contains the string keyHash.

Interesting. Actually, I have a laptop that I rarely use and which has not been turned on since I had made this change. Do I just need to make sure the network is turned off before opening my browser? Only using the browser extension (again, in Firefox), but I’m assuming the vault copy won’t get purged until the browser is opened?

Probably what I would suggest is the following:

  1. Make sure the internet is turned off. If you want to be extra careful, turn off your WiFi router before you even turn on your computer.

  2. Look for that local application data folder (%AppData%\Roaming\Mozilla\Firefox\Profiles\your_profile\storage\default\moz-extension+++[UUID]^userContextId=[integer]), and copy its contents to another location to have a backup copy in case something unexpected happens.

  3. Launch Firefox, and verify that the Bitwarden browser extension is locked but logged in (the shield icon should be blue/white with a padlock overlay).

  4. Unlock the browser extension. :crossed_fingers:

  5. Go to Settings > TOOLS > Export Vault, and export your vault in the .json format (not encrypted). The unencrypted .json file will contain all of your passwords in plaintext, and if you save them to an SSD drive, the data cannot be completely erased when the file is deleted (someone with physical access to your drive may be able to recover some or all to the data from the unused space on the drive). If this is a concern for you, I can provide guidance on how to more securely handle an unencrypted export.

P.S. I am moving these last few posts back to your own thread, so that @BostonPete’s thread does not get hi-jacked.

Don’t forget if you have any attachments these won’t be part of the vault export; so you’ll have to save them separately.

True, but @ddejohn has no way of retrieving any attachments from the cloud, since logging in no longer works. The above instructions are strictly for recovery of data from an off-line vault, so the attachments (or sends) will not be accessible.

i had a similar issue, i changed KDF to 600k, and changed my password to diceware, after that i had a trouble in login on my phone, but after several tries i logged successfully.

Unlike OP’s case, your case does not appear to be anything unexpected. If the KDF iteration count is set too high, some devices may fail to complete the PBKDF2-HMAC-SHA256 calculation because of insufficient computing power — this is more likely to occur on mobile devices and older hardware. When this happens, the error message is the same as you get when the password is incorrect.

In your situation, I would suggest reducing the number of KDF iterations. If you have a diceware passphrase consisting of 5 or more randomly generated words, then the increased number of KDF iterations are completely superfluous for security, and will just unnecessarily strain the computing resources in your phone.

Thanks, will give this a shot this weekend and report back.

1 Like

Just a reminder that if anyone needs to connect with the official support team, you can do so here: