I'm currently searching for the best way to prevent my software's webportal from bruteforce attacks and came up with the following idea:

  • 3 login attempts without any visual challenge
  • after 3 failed attempts show Google reCaptcha
  • allow another 3 attempts but now you have to click the captcha every time
  • if the last 3 attempts failed again lock the account

My idea just has major downsides and I hope you could give some advice:

  • what happens if the username changes at every login attempt? which account do I lock after 6 attempts?
  • how shall I log the 3 failed attempts (not dependent if those are 3 attempts to one account or one attempt for 3 different accounts) before showing the captcha?
    • IP? But what if lot's of people from a company network use the software at once?
    • Browser user agent? What if someone who tries the bruteforce attack simply changes the user agent at every login attempt?
    • Cookies?

2 Answers 2


Detecting brute force by user client behaviour alone is notoriously difficult. Due to distributed attacks, attacks against multiple usernames etc. means traffic patterns are hard to detect.

My recommendation, and the solution I use on almost all of my own systems, is to insert a simple delay into the process at the point of failure so if a user authenticates successfully it simply functions normally but for every failure insert a 2 or 3 second delay before declaring the failure.

For both humans and scripted clients (such as legitimate access to APIs etc.) this does not cause any issue, but for brute force attacks this slows the process down to an infeasibly slow speed even for every one of any likely number of parallel brute force threads (as long as passwords are complex of course.)

In addition, most server side languages release the CPU for 'sleep' commands and so this avoids this particular solution causing a DOS based on CPU time (though connection socket pools may still be an issue).

  • thanks for that fast response. I'll give the login delay a try for sure. The only concern I still face: I would only be able to delay the login for a specific username, am I correct? what if the bruteforce attack tries every username first? wouldn't it break that prevention?
    – 12dollar
    Oct 12, 2015 at 9:04
  • It's still easy to detect as if the result doesn't come back within a specific time then they can abandon it and try again, so you also need the same delay for successful attempts. But slowing down the speed of the bruteforce does help to render it less useful. Oct 12, 2015 at 9:54
  • @12dollar I've edited my answer to reply you on this.
    – dr_
    Oct 12, 2015 at 10:00
  • @12dollar - no, i'd put the delay in for any username... if it's for failed logins it won't upset any real users (even if there is a legitimate failure due to forgotten passwords, nobody will mind a few seconds delay in reporting the failure). As for James' comment, this is a good point, but abandonment on longer responses only works to a point, you can't trust the consistency of transmission delays that much can you? If you're worried then as James says, put it on all attempts, successful and failure. Oct 12, 2015 at 14:19

I think that your approach is pretty good.

Some notes on your proposed solution: A "failed login attempt" may be considered as such when e.g. it is the same username which is been tested. To protect against bruteforce attacks, you count the number of failed logins attempts in a lapse of time e.g. in your case, 15 minutes for 3 login attempts would be a good value. This would trigger the second level i.e. show the captcha.

Also introducing delay after each login attempt (as proposed by @DavidScholefield) is an excellent solution, and you can use it in conjunction with your method. You can either use:

  • a fixed 2-3 secs delay before showing the user the message about any failed login attempt, even if it's his first one
  • or you can use an increasing delay, which can be
    • either linear (e.g. 3 secs, 6 secs, 9 secs, 12 secs, ...)
    • or exponential (e.g. 2 secs, 4 secs, 8 secs, 16 secs, ...)

The beauty of fixed delay is that you don't have to log anything.
In the case of the increasing delay, you need to log on the username that failed the login (to prevent bruteforcing on one user) and also the IP address that failed the login (to prevent an IP address bruteforcing all users in your system, one try at a time).

The overlapping IPs from the same company is not a problem since users are supposed to use their own account. (If they don't, and they share account credentials, that's their problem.)

  • thanks for your reply. Regarding your answer I already stated my concern as a comment in @DavidScholefield's answer
    – 12dollar
    Oct 12, 2015 at 9:06

You must log in to answer this question.

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