3 ms·

The most familiar use of PBKDF2 for me is server-side hashing of client-supplied secrets wherein the hashed results are kept server-side and never revealed publ

The most familiar use of PBKDF2 for me is server-side hashing of client-supplied secrets wherein the hashed results are kept server-side and never revealed publicly. In this context of use, PBKDF2 is explicitly intended to slow down the server, not the [attacker/user]'s machine. Combine with heavy amounts of salt, and an attacker shouldn't be able to do much harm - even if the hashes are compromised. Are we saying PBKDF2 is used in other contexts and is less secure when used in these ways? Am I missing something?

echoer_lyrist 4y ago
It needs to be slow for attackers if the hash gets stolen like was the case with the LastPass breach.
kreco 4y ago
It looks strange to use "computational time" in order to slow down the server. In such scenario you are describing I believe an explicit delay like "thread_or_task.sleep()" would be even better? I believe that the "computational time" should be increased exactly for the "client-side" brute force. For example, if the attacker already have the password hash, the salt etc.
- bob1029 4y ago
  I think I am seeing the light now. Assume the database is compromised. Does it really matter how many iterations if you are up against a nation state attacker? I agree with the article on this one. Assume the database cannot be compromised (i.e. my original case of simply defending the login form from brute force). Using any form of computationally-intensive hashing is a total waste of energy. I agree - Task.Delay(xxx), not arbitrary PBKDF2 iterations. Taking to the absolute extreme - does hashing even matter if you can hypothetically guarantee no inappropriate access? Taking the extremes for what they are, I might be inclined to look at storing passwords as simple salted SHA256 or worse. All of this password hardening crap is starting to sound like a half-hearted attempt to protect users from themselves and provides little value to site operators. Being able to tell the public "well at least we used a billion iterations of argon2" doesn't make the root cause of that whole situation sound much better.
- codeflo 4y ago
  The purpose is to limit the damage in case the database is leaked.

echoer_lyrist 4y ago

It needs to be slow for attackers if the hash gets stolen like was the case with the LastPass breach.

kreco 4y ago

It looks strange to use "computational time" in order to slow down the server. In such scenario you are describing I believe an explicit delay like "thread_or_task.sleep()" would be even better? I believe that the "computational time" should be increased exactly for the "client-side" brute force. For example, if the attacker already have the password hash, the salt etc.

bob1029 4y ago
I think I am seeing the light now. Assume the database is compromised. Does it really matter how many iterations if you are up against a nation state attacker? I agree with the article on this one. Assume the database cannot be compromised (i.e. my original case of simply defending the login form from brute force). Using any form of computationally-intensive hashing is a total waste of energy. I agree - Task.Delay(xxx), not arbitrary PBKDF2 iterations. Taking to the absolute extreme - does hashing even matter if you can hypothetically guarantee no inappropriate access? Taking the extremes for what they are, I might be inclined to look at storing passwords as simple salted SHA256 or worse. All of this password hardening crap is starting to sound like a half-hearted attempt to protect users from themselves and provides little value to site operators. Being able to tell the public "well at least we used a billion iterations of argon2" doesn't make the root cause of that whole situation sound much better.
codeflo 4y ago
The purpose is to limit the damage in case the database is leaked.