3 ms·
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_
by 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 agoI 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 agoThe purpose is to limit the damage in case the database is leaked.