11–20 of 97 posts
Earlier quoted context omitted.
Doesn't PBKDF2 fix that as long as you use a very large number of irritations?
In theory, absolutely. In practice, bitwarden's server limits the max iteration count on a user account to something that remains insecure. They refuse to fix it. https://github.com/bitwarden/server/issues/589
Even if every BW vault leaked, if it takes half a day to run through 8 a-zA-Z0-9, it's not practical to do that for every vault. On the other hand, if I'm being targeted, even increasing that to a month wouldn't really matter.
Every "critical" site I use also supports u2f 2fa, which I've turned on. So even if they got my passwords, there's the 2nd factor they don't have.
tl;dr: Just use a damn password manager, even one that has arguable issues such as this improves the average person's security by orders of magnitude.
What's wrong with PBKDF2-SHA256? I use PBKDF2-HMAC-SHA256 for an almost-stateless password manager.
SHA and MD are fast hashers. You want slow hashers for password security like b-crypt and s-crypt.
Earlier quoted context omitted.
Doesn't PBKDF2 fix that as long as you use a very large number of irritations?
In theory, absolutely. In practice, bitwarden's server limits the max iteration count on a user account to something that remains insecure. They refuse to fix it. https://github.com/bitwarden/server/issues/589
Having 2fa enabled on all other accounts it makes me sleep better if somehow one day BW or any other password manager gets compromised.
As a rough estimate: a $2k bitcoin miner can do 2^45 SHA-256 hashes/sec whereas your $2k laptop can do 2^16 hashes/sec; the attacker has ~a billion x advantage over you that can be multiplied based on their funding. At that point, doing even 10,000 PBKDF2 hashes may not make much of a difference.
argon2, scrypt and other memory hard password hashing algorithms reduce the orders of magnitude advantages of the attacker by requiring RAM. Attackers might be able to purchase RAM cheaper than the defender, but nothing close to a billion times cheaper.
Addressing concern #3 (want to have a password set on a laptop that decodes in a reasonable amount of time on a low-end smartphone), you could restrict the RAM to some small amount (like 256MB) if you anticipate needing to use a low-end device. This will still be a vast reduction in the attacker's advantage over PBKDF2.
Earlier quoted context omitted.
Doesn't PBKDF2 fix that as long as you use a very large number of irritations?
In theory, absolutely. In practice, bitwarden's server limits the max iteration count on a user account to something that remains insecure. They refuse to fix it. https://github.com/bitwarden/server/issues/589
My threat model isn't a directed attack, it's DB dumps with unhashed or unsalted passwords from random websites. I want to use a unique password on every site, and password managers provide a convenient way of doing that. Even if every BW vault leaked, if it takes half a day to run through 8 a-zA-Z0-9, it's not practical to do that for every vault. On the other hand, if I'm being targeted, even increasing that to a m…
What's wrong with PBKDF2-SHA256? I use PBKDF2-HMAC-SHA256 for an almost-stateless password manager.
[0]: https://en.wikipedia.org/wiki/Password-authenticated_key_agr...
The model of hashing user plaintext passwords on server-side is itself a deeply flawed one. User password and master keys derived out of it should NEVER leave user-controlled computer. For authentication password-authenticated key agreement protocols [0] should be used, anything but it means that service does not treat user security as a high enough priority. [0]: https://en.wikipedia.org/wiki/Password-authenticated_…