I know one of the advantages of hash functions is that they are fast. However, I read somewhere (I don't know where exactly) that the speed is a disadvantage for password hashes when storing them in databases, but why is this so ? Would someone explain to me if being fast is a disadvantage for password hashing and why is this so ? (If possible could you also write some links to websites/papers describing this ?) Also are there other situations where being fast is a disadvantage for hash functions ? Thanks in advance for your help.

  • 1
    $\begingroup$ It's because the faster you can hash a password the easier it is to brute force a previously hashed password. You don't want that to be fast, you want that to be slow so that an attacker has more work to do and has to invest more (time, effort, money) in finding the password. $\endgroup$ Nov 22 at 17:13
  • $\begingroup$ Thank you very much @Swashbuckler. So the slower the process, the more time it will take for the attacker to brute force a hashed password. Now I understand it. Thanks ! $\endgroup$ Nov 22 at 17:31
  • 2
    $\begingroup$ Password databases leak/get stolen, and you want to make it as hard as possible for someone who's stolen your database to recover the passwords. This blog post is a pretty good intro; also, read this security.SE Q&A, this one here on crypto.SE, and Wikipedia. $\endgroup$ Nov 22 at 18:04
  • $\begingroup$ @GordonDavisson: Convert your comment to an answer. It can be helpful to the others. Comments can be deleted and your good answer in the comment will gone. $\endgroup$
    – mentallurg
    Nov 22 at 21:50
  • $\begingroup$ @Swashbuckler: I'd suggest you, too, to convert your comment to an answer. Comment can be deleted. But the answer will remain and can help other people. $\endgroup$
    – mentallurg
    Nov 22 at 21:51

Speed can be an advantage for one reason and a disadvantage for another.

When it comes to password security, the low cpu/memory requirements of a cryptographic hash brings a disadvantage, namely than if records or the database are exposed or hacked, an attacker has minimal work to do in order to brute force those hashes into a plaintext password.

This is because passwords are typically short and have less entropy than the preimage security of the hash function. If the passwords are huge and random, say 32 random letters and numbers, then a single fast iteration of the hash function is more than enough.

For security, you want a "password hashing function" to take as much time (compute resources) and memory as is feasible to slow down bulk attacks. However, this becomes a disadvantage to the server which will compare a hash to the database value, since in most cases that server must compute the hash from a user provided password.

An attacker may exploit that disadvantage by consuming large amounts of resources through coordinated mass login attempts of known or expected usernames, effectively a low bandwidth denial of service attack, the server is so busy keeping up with bogus login attempts that real users cannot login. This can be mitigated by throttling access attempts per IP address, per username, and also adding a delay before a login failure is shown. If the user does not exist, the server should not hash the password, but should return an error with an appropriate delay as if the user did exist, so that an attacker cannot infer the presence of usernames in the database.

PBKDF2 is an extremely common password hash, and at its core routinely uses HMAC, so something like 40000 rounds of PBKDF2-HMAC-SHA256 actually may take around 80000 times longer than a single hash iteration. If the server could previously perform 4 billion hash iterations per second, it may now only be able to do 50000 hashes of PBKDF2 before saturating its CPU completely. If you want no more than 10% of resources allocated to password checking, it would need to be throttled at 5000 login attempts per second... which may sound like a lot, but how many people do you think log into something like Gmail, Lastpass, or Salesforce at around 9am on a Monday?

There must be a balanced configuration and enough hardware to handle all user logins even under heavy load without a noticeable delay for those users, and prevent bad actors from denying service to those users. The strength of the password hash may also need to change over time as the resources of attackers increase, threat models change, etc. The cost of reputation damage may be many times higher than the cost of hardware to perform very expensive password hashes.

Are there other situations where being fast is a disadvantage? Off the top of my head I really cannot think of any, hash functions are typically used as part of a scheme, like digital signatures for example with a computationally expensive asymmetric algorithm involved, the security in that case comes from the size of the hash and the effective strength of the signing key, not the speed of the hash.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.