@BostonPete Thanks for the clarification.
Unfortunately, the results of this test do not prove that the password you have been entering matches the one stored on Bitwarden’s servers.
I assume that in Step #2, you did see kdfIterations: 600000, in which case we can confirm that this parameter was properly updated in the cloud database when you made the change to your KDF iterations value.
However, in Step #4, the value of the password field (i.e., the master password hash) in the Payload tab of the second post request is just showing the hash value being computed on your device based on the entered email and master password (and using the specified 600,000 PBKDF2 iterations); the “payload” is the information being sent from your device to Bitwarden’s server. We expect this to always match the Master Password Hash computed on the Bitwarden Crypto page, because that page essentially reproduces what goes on behind the scenes on your device whenever you log in to your Bitwarden account.
What other information do we have?
-
You said that tech support informed you the hashes you had provided did not match what they have. However, we don’t know whether they have just compared the submitted hashes to the hash stored in the cloud database (which would not be a meaningful comparison to make, and would only produce a match if there was something seriously broken in the server code), or if they applied the 100,000 server-side PBKDF2-HMAC-SHA256 iterations to your submitted hashes and then compared the results to the has stored in their user table (which is the comparison that you had requested). If we give the support staff the benefit of the doubt and assume that they did use the correct method of comparison (i.e., after applying server-side KDF), then the fact that there was no match indicates that the hash stored on the server is for a master password different from the one that you have been typing in to the crypto and login forms this week. On the other hand, if the support staff only made a direct comparison of your submitted hash values to the hash stored in the database, then the absence of a match tells us nothing of value — only that they did not understand your request.
-
You are unable to log in. Most likely, this is because the hash stored on the server is for a master password different from the one that you are using to log in. An alternative possibility is that the server code has a bug that causes the received master password hash value (
passwordin the POST request payload) to be incorrectly processed. -
The password that you have been using in tests this week successfully unlocked your vault backup. The fact that this password does not work for logging in could mean one of four things: (i) there is some strange bug in Bitwarden’s server code that is disrupting the authentication process for you; (ii) your master password hash in the cloud database was corrupted when you changed the KDF iterations; (iii) in the short time period from when your Saturday backup was made until you saved your changes to the KDF setting, you also changed your master password but don’t remember doing so (or didn’t realize that you were changing it); or (iv) what you’ve been using as a master password in testing this week is actually a PIN and not your master password. To disprove this last possibility, you could go back to your restored backup, unlock it with the internet disconnected (as you did previously), and then verify in the Settings that “Unlock with PIN” is disabled.
-
You were unable to reproduce the locally stored
keyHashusing the instructions I had provided. This could just be related to the problems you were having getting the downloaded and modified version of the crypto page to run on your computer. In the other hand, chasing down this lead might reveal additional clues.
Conclusion
With the ambiguity in some of the Bitwarden staff responses, it is difficult to say at this time what is going on. Based on the totality of the evidence available to date (as summarized above), my best guess is that the master password hash stored in the cloud database became corrupted when you changed the KDF iterations.