Account lockout is the most common defence against brute-force attacks, and it does the job: after a few failed passwords the account is locked, so an attacker cannot keep guessing. The problem is that the same mechanism can be turned into an application-level denial of service. By failing logins on purpose, an attacker can lock out real users, and in the worst case every account in the application. Below is why that happens, and the controls that stop brute force without taking your users offline: multi-factor authentication, rate limiting, a strong password policy, a CAPTCHA after a few failures, and uniform responses to failed logins.
What is a brute-force attack?
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.
Why can account lockout be worse than the attack?
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 can an attacker abuse account lockout?
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.
How do you stop brute force without causing a DoS?
| Control | Stops brute force? | Application-DoS risk |
|---|---|---|
| Multi-factor authentication | Yes, even if the password is guessed | None |
| Rate limiting / throttling (per account) | Yes | None: no permanent lockout |
| Account lockout | Yes | High: an attacker can lock out real users |
| Strong password policy (length + breach screening) | Raises the cost | None |
| CAPTCHA after N failures | Yes | None |
| Random login delay | Raises the cost of sequential guessing | None |
| Uniform failure responses | Blocks username enumeration | None |
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:
- Multi-factor authentication (MFA): the most effective control by far. Even if an attacker guesses the password, it is not enough on its own; OWASP describes MFA as the single best defence against automated password attacks.
- Rate limiting and throttling: cap the number of attempts per account (and per source) and add an increasing delay or a temporary block after repeated failures. Unlike a hard lockout it slows or stops an attacker without permanently disabling the account, so it counters brute force without the application DoS this post is about. It is the cleanest answer to the problem.
- Strong password policy: a weak password can be found in a handful of requests. Current guidance (NIST SP 800-63B) favours length over composition rules, so encourage long passphrases and screen new passwords against lists of known-breached credentials rather than forcing a mix of character classes. The password should never be equal to the username.
- Requiring CAPTCHA after some failed attempts: after 3 to 5 failed attempts, instead of locking out the account, it is possible to require a CAPTCHA.
- A small random delay on failed logins: a random value (for example between 1 and 3 seconds) raises the cost of sequential guessing while letting legitimate users in immediately. On its own it is only a speed bump, since an attacker can send requests in parallel, so pair it with rate limiting.
- Uniform responses for failed logins: return the same generic message, status code and timing whether or not the username exists. This avoids the username enumeration described earlier, which is what lets an attacker single out valid accounts in the first place.
Last but not least: always have a look at the OWASP Authentication Cheat Sheet.
Key takeaways
- Account lockout stops brute force but creates an application-level DoS: an attacker can deliberately lock out legitimate users.
- Lockout also enables username enumeration, floods help desks with unlock requests, and lets an attacker keep accounts permanently locked.
- Prefer controls that stop attackers without disabling accounts: multi-factor authentication, rate limiting and throttling per account, a strong password policy (length plus breached-password screening), a CAPTCHA after a few failures, a small random delay, and uniform failure responses.
- Do not forget administrative accounts: if they are exempt from lockout, decide how they are protected from brute force instead.
Be aware when locking out accounts. BeDefended.
Thanks for reading.
