For authentication controls, Owasp gives advice to prevent brute-force attacks by locking out account, and I see this kind of advice in several places (blocking by source IP after failed logins, blocking by account ...).

Why ?

I mean, two cases here :

  • either you securely store your passwords in database with costly verification (bcrypt, argon2, ...) : in this case, your passwords are supposed to resist to offline attack, when the attacker has direct read access to the database. And i think they will : if password verification takes on server side ~ 0.05s with a decent hardware and you impose a password length of 7 character AND forbid common password (included in a potentially big list), it will take on average 0.05 * 62^7 / (2*3600*24*365) = 2 800 years to decrypt each password (assuming users chose passwords of 7 characters in [a-zA-Z0-7]). Unless your threat model imply attacker having a really big computing power, I find it enough. And online attack (brute-force using the login form) is slower than offline attack : is there still a need to block the attacker if its bruteforce attempts are bound to fail for quite a long time ? And yes, the brute-force attempt will be a kind of (D)DoS, but this has to be mitigated by general anti-(D)Dos techniques which are not specific to login forms.

  • either you do not store your password securely (fast-to-compute hashes, no salt, no hashes at all ...) : this is a problem and you should first consider securely storage of passwords. And if you can't (software legacies ...), simply adding a 200ms delay to each password verification achieves a similar protection in the login form (but not in the case of database leak / offline attack), and is far more simple to implement.

In none of these 2 alternatives I see blocking brute-force attempts a good solution. It adds complexity and potentially creates DoS vulnerabilities.

  • 1
    Your first case makes significant assumptions (e.g. disallowing weak passwords, and time to attempt hashes). Rate limiting helps, but locking out is the "fail closed" approach to protect an account under attack. Yes, you could get Denial of Service, but sometimes that is the preferable choice.
    – JesseM
    Commented Nov 9, 2018 at 18:37

2 Answers 2


Secure password storage alone does not help against brute forcing trivial passwords. If all the attacker has to do is try 100 passwords to get to the users account then slow password verification is not a real problem. Apart from that password verification cannot be too slow because otherwise a DOS on the system can be created by just trying to log in.

Regarding your example: if a password verification takes 0.05 seconds then the system can only verify the login of 20 users within a single second. For many use cases this is too slow. On the other hand the attacker only needs 5 seconds to brute force 100 passwords and at the same time makes the system unusable for others (i.e. DOS).

If instead the password verification takes only 0.01 second but there is a limit of only 3 attempts within a 30 seconds for a single user account than the attacker would need 1000 seconds to try 100 passwords and at the same time the system can handle other users without problem.

Apart from that the common password hashing is not intended to deal with brute force attacks against a single account. The salting and hashing complexity are instead intended to make it impossible to crack passwords en masse.

  • 1
    There's also indirect concerns. Password reuse is rampant and some users chose passwords which are deprivations or simple modifications of previously compromised passwords. If I know what a users password is similar to it reduces the amount of passwords I need to try significantly.
    – Daisetsu
    Commented Nov 9, 2018 at 18:10

Hashing is reasonably fast so it's perfectly feasible to hash a few thousands of passwords per second. Of course, there are hashes that are designed to be seriously slow and hashes that are designed to be secure AND efficient. However, if you choose a hash that is too slow and you have a lot of users then you might stall legit login attempts because your server can't handle the load.

simply adding a 200ms delay to each password verification achieves a similar protection in the login form

Yes, but a delay is usually a sleep which means the executing process (or fibre) gets blocked for 200ms and if if you make a thousand brute-force requests per second then you'll either have thousand processes hanging or a thousand fibres hanging - none of which is ideal. Also, a delay does actually pretty much nothing against brute-force requests since requests occur in parallel. If I can test 1000 passwords then I don't care about that 200ms delay because it's just going to delay the first response. If you throw a thousand rocks down a cliff and they take 200ms to hit the ground that 200ms does not limit the amount of rocks that you can throw - it just increases the delay until the first rock hits the ground.

You must log in to answer this question.

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