Live data from Hacker News

Why we are still using PBKDF2-SHA256 despite being aware of its limitations

github.com

1–10 of 97 posts

Re: Why we are still using PBKDF2-SHA256 despite being aware of its limitations

#7
post #6
post #2

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.

Doesn't PBKDF2 fix that as long as you use a very large number of irritations?

Re: Why we are still using PBKDF2-SHA256 despite being aware of its limitations

#9
If I understood correctly, the points are:

- using longer passwords (or salts) is better than increasing the number of rounds

- having the same database on different devices (top-CPU x older cellphone) have impacts on the performance for the user but not for the attacker (as a powerful hardware will be used)

Seems fair, for the average user. And the top user will prefer a longer password anyway.

Re: Why we are still using PBKDF2-SHA256 despite being aware of its limitations

#10
post #7
post #6

Earlier quoted context omitted.

SHA and MD are fast hashers. You want slow hashers for password security like b-crypt and s-crypt.

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

Post reply on HN