Detecting the attack
Of course, before we fight a brute force attack, we must first detect it. Specialists from the International Institute of Cyber Security have listed a series of recommendations to mitigate these attacks. Make sure your application has tools to monitor network traffic. At least two of these would be useful: metrics and logs.
- HTTP metrics should be sufficiently detailed to determine the URL and method of each incoming request, the status and number of responses produced, etc. You can then create special alerts in the monitoring tools that will tell you about any suspicious behavior.
- Logs will provide more detailed information about each request that cannot always be compiled as a metric. It can contain data like request headers, source IP, request body, etc. Analyzing them could help in understanding details of the attack and propose defense tactics.
IP Block
First thing that can come to mind after detecting an attack is blocking the IP address of the attacker. But that’s not a good way to stop an attack, either because the attacker can easily overcome it by changing its IP address, or because this solution can block a public IP address, cutting access to many users.
User Block
Another idea might be block accounts with too many failed login attempts. This would require a special action from the user to be able to unlock it.
This is a risky approach. An attacker could make numerous attempts with many valid user names, and you could end up blocking a large part of your application’s users. Most of them are likely to unlock their accounts the first time it happens. But will they do it the second time and then again and again? Over time this can keep users away from your application and that’s something we don’t want to happen.
Captcha
No matter how the Completely Automated Public Turing Test to tell Computers and Humans Apart (CAPTCHA) is implemented, the distinguished “proof that you are not a robot” is always irritating. Very often it is not convenient to solve CAPTCHA on the desktop and sometimes in mobile versions it can become an obstacle for the user. In applications that prioritize ease of use, CAPTCHA should be considered as a last resort.
In addition, many CAPTCHA implementations are vulnerable to attacks, using neural networks, or social engineering, in which large groups of people receive a payment to solve CAPTCHA riddles in real time.
If you want to or should add CAPTCHA to your application’s login page, consider the following:
- Do not ask to resolve a CAPTCHA before login, it is better to do so after one or more failed attempts in a row for a given username. This way it will be less annoying for real users.
- Ask to resolve the CAPTCHA for non-existent username signs to complicate the attacker’s task of finding registered user names.
- Do not use your own CAPTCHA. Use an existing one, which has been tested and possibly paid for.
Latency/delay
In a brute force attack, the hacker will try to access by testing many passwords. Introducing a delay between failed login attempts would significantly slow the process, which will probably make the whole process too slow for the attacker. That extra latency won’t bother real users, as they probably don’t mind waiting a few more seconds if they made a mistake typing their password. For longer periods, such as 10 seconds, consider showing the user some type of countdown timer.
Ask the User for an Additional Secret Question
The secret question and its corresponding answer are configured in the user’s profile. Present this option for accounts with too many failed attempts, waiting for the user to provide a valid response. Be sure to ask that question also for invalid logins, so that the attacker has no other way to discover real accounts.
Trick Brute Force Tools
Some of the penetration test tools can be used in a brute force attack. These programs send requests with the User-Agent header to a default value, a revealing sign of the attack tool.
By randomly returning the response for requests with that header, an application can deceive the attacker who will no longer be able to distinguish between successful and failed attempts. It will work with beginner hackers who do not know how to solve this. Anyway, keep in mind that this is not a totally secure solution.
Information security specialist, currently working as risk infrastructure specialist & investigator.
15 years of experience in risk and control process, security audit support, business continuity design and support, workgroup management and information security standards.
