What are brute force login attacks and how can I protect my users and applications from them?
Ask a question
Rob Shapland, one of SearchSecurity.co.UK's resident security experts, is standing by to answer your questions. Submit your questions today. (All questions are treated as anonymous.)
A brute force login attack is one of the most common (and least subtle) attacks conducted against Web applications. The aim of a brute force attack is to gain access to user accounts by repeatedly trying to guess the password of a user or a group of users. If the Web application does not have any protections in place against this type of attack, it’s possible for automated tools -- which are readily available on the Internet -- to submit thousands of password attempts in a matter of seconds (or less), making it easy for an attacker to beat a password-based authentication system.
Brute force login attacks can be conducted in a number of ways. If the length of the password is known, every single combination of numbers, letters and symbols can be tried until a match is found. However, this is a slow process, especially as the length of the password increases (which is why long passwords are better than short). The alternative is to use a list of common words, which is known as a dictionary attack. A dictionary attack will generally try all English words, with the option of adding numbers or doubling up the word as the potential password. This has far fewer combinations, but still has a high chance of finding the correct password.
Rather than trying many passwords against one user, another brute force attack method is to try one password against many usernames. This is known as a reverse brute force attack. This technique is worth noting as it is where most account lockout policies fail. Reverse brute force attacks are less common, however, because it’s often difficult for the attacker to compile a sufficiently large volume of usernames for the reverse attack.
Preventing brute force attacks
There are a number of techniques for preventing brute force attacks. The first is to implement an account lockout policy. For example, after three failed login attempts, the account is locked out until an administrator unlocks it. The disadvantage of this method is that multiple accounts can be locked out by one malicious user, causing a denial of service for the victims and lots of work for the administrator.
A better, albeit more complicated technique is progressive delays. With progressive delays, user accounts are locked out for a set period of time after a few failed login attempts. The lock-out time increases with each subsequent failed attempt. This prevents automated tools from performing a brute force attack and effectively makes it impractical to perform such an attack.
Another technique is to use a challenge-response test to prevent automated submissions of the login page. Tools such as the free reCAPTCHA can be used to require the user to enter a word or solve a simple math problem to ensure the user is, in fact, a person. This technique is effective, but has accessibility concerns and affects usability of the site.
Any Web application should enforce the use of strong passwords. At a minimum, requiring users to choose passwords of eight letters or more with some complexity (letters and numbers, or requiring one special character) is an excellent defence against brute force attacks when combined with one of the techniques outlined above.
It may appear, at first, useful to use a tool that automatically reads Web logs and alerts an administrator if multiple attempts come from one IP address. However, it is fairly simple for an attacker to use a variety of tools to automatically and regularly change his or her IP address.
It is important to ensure the Web application employs at least one of these techniques for defending against brute force attacks if your users are to trust the security of their personal data. Using the techniques outlined in this article should provide a robust defence against this common type of attack.
This was first published in June 2012