I’m not from Bitwarden, but I hope you don’t mind me chiming in. Although the scenario described is theoretically possible, it is unlikely to cause any real damage. Let’s examine it:
The number of KDF iterations is cached in your local vault, so none of this applies unless you are logging in to a Bitwarden client. If you don’t have a locked vault on your device and you are logging in, then there is an unauthentication prelogin in which fetches the number of KDF iterations from the server, that part is true. This is the the part of the story where Mr. Palant raises the spectre of a rogue Bitwarden server that returns
kdfIterations: 5000 instead of
kdfIterations: 2000000. OK, what are the consequences? Your client app now hashes your master password 5000 times (instead of 2000000) to derive the Master Key, which is then hashed 1 more time and transmitted to Bitwarden’s authentication servers, where another 100,000 iterations of hashing take place to finally produce a final master password hash. To authenticate you, Bitwarden’s authentication server then compares the resulting final master password hash to the previously stored final master password hash (which was saved in the cloud database the last time that you changed your master password). Well, guess what? If the stored hash was generated using the correct number of iterations (2,100,001) and the transmitted hash was generated using a lower number of iterations (105,001), then the two hashes will not match, so your login attempt will fail. At worst, such an attack will result in denial of service.
If the server that handles the prelogin call (to return the KDF iteration value) is the same as the server that authenticates your master password (or if they are two different servers, and the attacker has gained control of both — without anybody at Bitwarden noticing), then the rogue authentication server would receive a copy of your master password hashed only 5,001 times. The attacker could then start working on a brute-force cracking attempt against this hash (which would be up to 400 times easier than using the MAC). In the meantime, what happens? Most likely, the rogue authentication server will tell the client that login failed. The alternative is that the rogue server pretends that the authentication was successful, and then transmits the encrypted vault and the Protected Symmetric Key from the database server to your client app. Your client app now attempts to derive the account encryption key from the downloaded protected key, but because the Stretched Master Key was derived using the wrong number of iterations (5,000 instead of 2,000,000), this operation produces a garbage encryption key. The message authentication key (MAC) will also be incorrect. As a result, your client app will not be able to decipher any of your vault contents. Not sure if the app will produce an error message, but you will definitely notice.
The end result, is that very quickly, it will become apparent that none of Bitwarden’s users can log in, or that they can log in but cannot see their vaults (coupled potentially with error messages). Thus, this type of attack will be discovered and shut down very quickly. Any users whose master password hashes were compromised and who were using a weak master password would have plenty of warning to change their account passwords before any damage could be done. Those with a strong master password (a passphrase consisting of 5 random words or more) wouldn’t need to loose any sleep at all — even someone using a passphrase of only 4 words would have several months’ head start against an attacker with a $150k rig containing 100 GPUs, and decades’ worth of time before a lesser adversary would have any reasonable chance of cracking the master password.