At worst, such an attack will result in denial of service. 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. 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). 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. Palant raises the spectre of a rogue Bitwarden server that returns kdfIterations: 5000 instead of kdfIterations: 2000000. This is the the part of the story where Mr. 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. 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. Although the scenario described is theoretically possible, it is unlikely to cause any real damage. I’m not from Bitwarden, but I hope you don’t mind me chiming in.
0 kommentar(er)
