I understand most of the concepts behind hashing password but this one still escapes me.

I understand that you want the hash to take some time ( a couple milliseconds) so the attacker can't brutteforce. But at the same time you don't want the hashing to take too much computer resources.

Why don't you just hash and then sleep for 0.1 seconds?


3 Answers 3


Passwords are hashed for the case that an attacker can read the hashes from the database (e.g. SQL-injection). Afterwards he can brute-force with the full speed of his own environment, often with a GPU, this is called an offline attack.

A sleep on the other hand could only protect from online attacks, even then an attacker could make multiple requests and wait for the results which are a bit delayed but are not slower.


Hashes protect passwords in case the attacker gets hold of the password database. If adding sleep to authentication would be enough to prevent brute forcing it would automatically mean that your threat model allows for storing the passwords in the clear because you're only worried about online attacks. Since almost no threat model assumes that your systems won't be compromised (it would be very irresponsible to assume that), you have to protect the passwords so that they are resilient against offline attacks and then whatever sleep you added to your code is completely irrelevant.


The important thing is that the attacker should not be able to brute-force to gain access. That doesn't necessarily mean that the hashing algorithm has to be slow. The end-to-end login flow should be slow enough. This can be achieved in several ways:

  1. As you mention, change the hashing algorithm to be slow.
  2. Disallow login attempts for a certain duration after a certain number of wrong attempts.
  3. Mandate passwords of greater lengths and complexity. (Greater length increases the number of possibilities to be tried for brute-force attempt)

Option 1 and 2 are of no use if the hacker gets access to the hashed form of the password and the hashing algorithm.

Edited with the suggestion from the comment:

Option 2 is of no use if the hacker gets access to the hashed form of the password and the hashing algorithm.

Option 1 is also useless if the slowness is largely due to sleep that can be worked around (for example if the source code of hashing algorithm is available, then it's easy to delete the sleep. Other options are possible without the source code too)

  • 2
    Your first point is incorrect, if the hash algorithm is slow, this will thwart offline brute-force attacks. The slowness has to come from the necessary cpu time and not from a sleep() that can be circumvented though. That's why one should use a slow hash algorithm with a cost factor. Aug 14, 2015 at 8:12
  • 1
    You need to make sure you are separating the concepts of having a slow algorithm and a slow hashing program.
    – schroeder
    Aug 16, 2015 at 2:56

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .