my bruteforce prevention has major downsides - any ideas?

Question

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?

Answer 1

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).

Answer 2

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.)