When brute force prevention can turn in DoS

Today I want to talk about another common problem web developer face: brute force attacks

However, especially I want to talk about one of the most adopted solution to this problem: account lockout. Since this is one of those cases where the solution could be worse than the problem.

But, let’s go step by step.

What Are Brute Force Attacks?

Brute force, also known as “exhaustive search” and many other alias is a general problem-solving technique that consists of systematically trying every possible candidates until the correct one is found.

If your application requires user authentication, then you could be a good target for a brute-force attack.

This is a common threat for applications since an attacker can use this “password-guessing” technique, for example on the login form, to systematically check all possible passwords, by trying every combination of letters, numbers, and symbols, until he can successfully login.

The Problem

As I said previously, one of the most recommended and developed solution is to implement an account lockout policy: for example, after three or five failed login attempts, the account is locked out until an administrator manually unlocks it.

This is an easy-to-implement and effective solution against brute force attacks, since the attacker cannot try all the combinations.

There are a lot of web applications and plugins for the most used CMS that implement this easy and effective solution.

However, despite this one solves the brute force problem it introduces a potential application denial of service (DoS), because an attacker can intentionally tries wrong passwords until the accounts are locked out.

An application DoS differs from the classic DoS attack since it abuses the business logic of the application (so at OSI layer 7) to disrupt the service. Therefore, firewalls, routers, load balancers and other network appliances continues to work without any problem because no flood is coming at network level.

This type of application DoS could be worse than the brute force attack since a brute force attack may be practically exploitable only with accounts that have a weak password configured instead an application DoS could potentially prevent the access to a large number of users, including those ones who have correctly defined a strong password.

But this is not the only problem related to account lockouts since:

• It is not possible to lockout out an account that does not exist so, depending on the error response, an attacker can enumerate valid usernames
• A massive account lockouts attack can overwhelm administrators or help desk with a flood of requests
• An attacker can continuously, and automatically, lock out the same accounts, even immediately after the administrator unlocks them, effectively disabling the accounts

How an attacker could exploit it

Now suppose an application that implements numerical usernames (and I’m pretty sure that you know or use applications with numerical usernames): an attacker could easily create a script that iterates all the users and for each one it tries some wrong passwords until the account is locked out.

Even if the application does not use numerical usernames, the attacker may be able to harvest valid usernames in other ways: it is quite common to find user enumeration vulnerabilities (for example on “login”, “forgot password” or “create account” pages) and then he can carry on the attack on all the harvested accounts.

Lastly…What if also the administrative accounts are subject to the lockout policy? Who will unlock the “unlockers”?

And if administrative accounts are not subject to the lockout policy, how they are protected? Maybe no protection against brute force attacks is configured on these accounts if the lockout policy is the one designed by developers. But administrative accounts are the most desirable account to attack.

The Solution

We already said that a lockout policy is an effective solution against brute force attacks but we also know that it could introduce even worst issues so we have to find the right balance.

Following some advices that can be implemented (better if all together) to prevent brute force attacks without introducing application DoS:

• Strong password policy: without this, your password may be found with few requests. An example of a good password policy for web application could be requiring at least 10 chars, presence of digits, alphabetic (both lowercase and uppercase) and special characters. And obviously the password should not be equal to the username.
• Random delay in case of failed login: the success of the attack is time-dependent: therefore introducing a delay (e.g. a random value between 1 and 3 seconds) can slow down an attack until it becomes practically infeasible. At the same time, this solution lets legitimate users to log into the application immediately.
• Requiring CAPTCHA after some failed attempts: after 3–5 failed attempts, instead of locking out the account, it is possible to require a CAPTCHA.
• “unpredictable” responses for failed logins: since the most of the times an automatic (and “standard”) tool is used to carry on a brute force attack, the implementation of “unpredictable” responses (for example with different status codes, content and redirects) makes the automatic identification of valid credentials more difficult and it can discourage all but the most dedicated attackers.

Last but not least: always have a look at OWASP resources.

Be aware when locking out accounts. BeDefended.

Thanks for reading.