Bitwarden design flaw: Server side iterations
1–10 of 264 posts
Re: Bitwarden design flaw: Server side iterations
#2Other than the low amount of default iterations (at least compared to the OWASP recommendation [0]) the article doesn't explain why the server-side hashing is "useless" and what the design flaw actually is. Am I missing something?
[0]: https://cheatsheetseries.owasp.org/cheatsheets/Password_Stor...
Re: Bitwarden design flaw: Server side iterations
#3If you think it's ok to be putting all your passwords on some random server owned by a random company then I don't know if you care about any other design flaws. This also includes the websites you visited and just happened to either accidentally or on purpose save your login.
Now multiply the privacy/security implications of that when said company is pumped and dumped by a major VC.
Re: Bitwarden design flaw: Server side iterations
#4Other than the low amount of default iterations (at least compared to the OWASP recommendation [0]) the article doesn't explain why the server-side hashing is "useless" and what the design flaw actually is. Am I missing something? [0]: https://cheatsheetseries.owasp.org/cheatsheets/Password_Stor...
Quoting directly:
> the 100,000 PBKDF2 iterations on the server side are only applied to the master password hash, not to the encryption key
The attacker doesn’t need to break the master password hash, so it’s irrelevant. This is elaborated in the link directly following the above quote:
> But that protection only works if the attackers are stupid enough to verify their master password guesses via the authentication hash.
Re: Bitwarden design flaw: Server side iterations
#5Other than the low amount of default iterations (at least compared to the OWASP recommendation [0]) the article doesn't explain why the server-side hashing is "useless" and what the design flaw actually is. Am I missing something? [0]: https://cheatsheetseries.owasp.org/cheatsheets/Password_Stor...
If I understand correctly, the problem is that the hash created on the client side is used to create the encryption key before the server side hashes are applied. Only the master password uses the extra server side hashes.
Re: Bitwarden design flaw: Server side iterations
#6Other than the low amount of default iterations (at least compared to the OWASP recommendation [0]) the article doesn't explain why the server-side hashing is "useless" and what the design flaw actually is. Am I missing something? [0]: https://cheatsheetseries.owasp.org/cheatsheets/Password_Stor...
> the 100,000 PBKDF2 iterations on the server side are only applied to the master password hash, not to the encryption key
So only the password hash itself gets the extra iterations. The diagram and the text of the whitepaper seem to be at odds, though. The diagram doesn't show extra iterations for the encryption key, but the whitepaper says:
> PBKDF-SHA256 is used to derive the encryption key from your Master Password. Then this key is salted and hashed for authenticating with the Bitwarden servers. The default iteration count used with PBKDF2 is 100,001 iterations on the client (this client-side iteration count is configurable from your account settings), and then an additional 100,000 iterations when stored on our servers (for a total of 200,001 iterations by default).
Re: Bitwarden design flaw: Server side iterations
#7If you think it's ok to be putting all your passwords on some random server owned by a random company then I don't know if you care about any other design flaws. This also includes the websites you visited and just happened to either accidentally or on purpose save your login. Now multiply the privacy/security implications of that when said company is pumped and dumped by a major VC.
There's a version of this sort of password manager that is safe. Not saying Bitwarden is it, just that strong, well-implemented cryptography can get us there.
Re: Bitwarden design flaw: Server side iterations
#8If you think it's ok to be putting all your passwords on some random server owned by a random company then I don't know if you care about any other design flaws. This also includes the websites you visited and just happened to either accidentally or on purpose save your login. Now multiply the privacy/security implications of that when said company is pumped and dumped by a major VC.
You can self host bitwarden, using either their implementation or open source vaultwarden
Re: Bitwarden design flaw: Server side iterations
#9If you think it's ok to be putting all your passwords on some random server owned by a random company then I don't know if you care about any other design flaws. This also includes the websites you visited and just happened to either accidentally or on purpose save your login. Now multiply the privacy/security implications of that when said company is pumped and dumped by a major VC.
You can self host bitwarden, using either their implementation or open source vaultwarden
Exactly, BitWarden is not as shit as others like LastPass or 1Password.
Re: Bitwarden design flaw: Server side iterations
#10I still haven't seen a clear explanation of how the # of iterations scales in relation to password length.
If it is true a few extra characters is as good as having sky-high iterations, the guidance should be on 'forcing' users choose long-enough passwords, not in this nitpicking over the 'right' # of iterations.