We have a web application where the input fields for login are: username and password. In order to prevent brute force attacks, we have implemented a lockout function for 5 invalid tries of valid username but the incorrect password.

What the penetration testers did was use the same password but enumerated usernames until a valid one was found. No lockout can prevent that since the username field is always changed. They did enumeration at a rate just below the minimum threshold for the firewall to categorize this as an automated attack and block it.

It seems the only way to handle this is programmatically. I have some solutions in mind but I don't want to reinvent the wheel. Are there are solutions on how to handle this programmatically?

  • The technique is called "password spraying" and is quite common.
    – schroeder
    Mar 10, 2020 at 7:31
  • Why is your automated check at the firewall? Why not do a check based on IP on the server where the login logic is?
    – schroeder
    Mar 10, 2020 at 7:34

2 Answers 2


You need to correlate the failed logins on the server to some characteristic the attacker has. Typically, this can be the IP, but there may be other options depending on how your app is built and what data it collects.

This means you need to keep track of failed logins across all users for some window of time.

Once you identify an IP that is failing to log in across many accounts, you have some difficult options regarding how to respond. You could block the IP, which could lock out all legitimate users using that IP, or before lockout, check to see if the IP has been used by other legitimate users (i.e. determine if the IP is likely legitimate or not).

IP blocking is crude and error-prone. It is just as easy for attackers to rotate through IPs as it is to rotate through usernames. You also risk the chance of locking out your legitimate users.

You could also tackle the problem on a different layer altogether. You could implement 2FA, which protects the users and means that you don't need to protect user passwords through log analysis. Or you could make the decision that users who are vulnerable to password spraying need education or better password guidance rather than trying to protect them against themselves.

The problem here isn't that your app is vulnerable to password spraying, it's that the passwords are easy to guess.

  • As mentioned, IP addresses are unreliable. Another characteristic of the specific endpoint could be the session ID - you could simply start a session at the first login attempt and track the user based on that. From an attacker's perspective this is more easy to bypass than an IP address check but has the benefit of being able to track multiple users under a single IP.
    – Elhitch
    Mar 10, 2020 at 8:10

Well all you can really do is slow down the Bruteforce time, making it unlikely to be achieved in a practical time, also you should implement another auth layer beyond of what you have... here is why:

Your first solution has sort of a "Denial of Service" flaw because a malicious user can use known and valid 'User_ids' to block their accounts with intentionally bad parameters... denying access to your application for some users, all of them if they are an incremental id.

So you need to have an extra auth-layer for those cases where a legitimate user forgets his password or was blocked by a bad user, this can be worked around by answering a security question, SMS message trusted IP, be creative here... think on how big companies do it...

Now to slow down a brute force attack you need to involve TIME first, limit user "IP Address" to make a login request only each second, this reduces the number of Bruteforce tries. If you block a user account, block it for a certain time (a day maybe?) unless they authorize themself with the second layer for legitimate users.

Have a LOG file where you save all faulty logins and check if IP Address has a limit number of tries (10 maybe?)... if so 'Black-List" IP for a day or more... this way an attacker could only try 2 accounts in 10 seconds... and be blocked for a day... unlikely to brute force anything.

This way you protect against attacks and also your legitimate users can recover their accounts.

Note: You may need to reset the log file every often so legitimate-dumb users that have trouble with their password don't get their IP banned. And always check before login if IP is banned.

  • Unless the IP is shared, as can be the case when the users are from the same company. Your suggestions for the specific settings are not realistic. Your whole section about the account lockout DoS should be a side comment.
    – schroeder
    Mar 10, 2020 at 7:38

You must log in to answer this question.

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