Preventing a Brute Force or Dictionary Attack: How to Keep the Brutes Away from Your Loot

Get started

Corporate intranet sites can contain confidential data such as project plans and customer lists. E-commerce sites often store users’ e-mail addresses and credit card numbers. Bypassing or evading authentication in order to steal this data is clearly high on a hacker’s priority list, and today’s hackers have a large library of authentication evasion techniques at their disposal.

Session hijacking attacks such as cross-site scripting can steal a user’s authentication token and transmit it to a malicious third party, who can then use it to impersonate the legitimate user. SQL injection attacks can also be very effective at bypassing authentication. By sending a specially formatted user name and password combination containing SQL code to the log-in form, an attacker can often trick the server into granting him unauthorized access.

These types of attacks get a lot of attention since they are creative, elegant and effective. However, there is another type of attack that can be just as effective, if not as elegant or creative. A brute force attack (or dictionary attack) can still be a dangerous threat to your Web site unless proper precautions are taken.

The brute force attack is about as uncomplicated and low-tech as Web application hacking gets. The attacker simply guesses user name and password combinations until he finds one that works. It may seem like a brute force or dictionary attack is unlikely to ever succeed. After all, what are the odds of someone randomly guessing a valid user name and password combination? Surprisingly, the odds for a brute force attack can be quite good if the site is not properly configured. There are several factors that work to the hacker’s advantage, the most important of which is human laziness.

Generally, people do not remember complicated passwords very well. If users are allowed to create their own passwords, they will often create very simple ones like “password”, “1234”, their spouse’s name or their favorite sports team. Passwords like these are easy for the user to remember, but unfortunately they are also easy for someone else to guess. Furthermore, any serious hacker who attempts a brute force attack will not be sitting at a Web browser, guessing at authentication credentials and typing them in. He will be using an automated tool for the brute force attack that can make thousands of requests per minute with credentials generated from a large list of possible values. Often this list is an actual dictionary, hence the term “dictionary attack.” If a user chooses a common password, such as a dictionary word, the automated tool will eventually guess it, and the user’s account will be compromised.

Also, once the brute force attack has revealed a valid user name and password combination for one Web site, the hacker knows that the same combination is likely to work for other Web sites. In a study conducted by the University of Wichita, more than half of the test subjects reported using the exact same password for multiple sites. This laziness works to the hacker’s advantage. If, for example, a hacker is able to use a dictionary attack to obtain a valid user credential for Amazon.com, then it is probable that the same credential would be valid for other popular Web sites, such as eBay.

Of course, a password is only half of the required log-in credential. A user name is also required. While it is less likely that a dictionary word would be used as a user name, there are still some common user names that hackers are certain to try with a brute force attack. First among these are “admin” and “administrator”. These names are especially dangerous since they are not only easily guessed, but the accounts they represent are usually highly privileged administrative accounts. If the hacker’s dictionary attack could gain access to an administrative account, he could probably do much more damage to the system than he could if he gained access to a regular user’s account.

Administrative accounts are not the only problem. Many Web applications and Web application frameworks create default users during installation. If the site administrator does not remove these default users or at least change their passwords, these accounts will be easy targets for a dictionary attack. Finally, when users are allowed to choose their own user names, they often choose their e-mail address, since it is easy to remember. Once again, the user’s laziness is a benefit to a hacker using a brute force attack. Armed with a list of e-mail addresses (perhaps obtained from a spammer) and a dictionary of passwords (easily obtained anywhere), an attacker has an excellent chance of breaking into at least one user’s account.

The primary defense against a brute force attack must be enforcement of a strong password policy. As mentioned earlier, dictionary words make poor passwords. Password size is also important: The longer the password, the more difficult it will be to force. While there is no strict definition of a strong password that will be harder to determine via a dictionary attack, some good guidelines would be:

• Minimum length of at least seven characters
• Must include both upper and lower case characters
• Must include numeric characters
• Must include punctuation

These guidelines may seem overly strict, but there is little chance that a password created with these restrictions will be found with a brute force attack. There are almost 70 trillion combinations of characters that can be seven digits long and can include upper case characters, lower case characters, numbers and punctuation. Even a dictionary attack tool that could make one hundred requests per second would still take over 11,000 years before it would be statistically likely to guess the password.

Obviously, most Web sites will want to block a dictionary attack much sooner than 11,000 years into the attack. Many organizations use an intrusion detection system (IDS) to detect an abnormally high number of requests coming from a single user. This is a good idea, but it is not sufficient to prevent the brute force attack. A clever hacker will simply reduce the bandwidth used by his automated tool until it falls under the alert threshold of the IDS.

Another common defense strategy against a dictionary attack is to automatically disable an account after a certain number of failed log-in attempts. For example, if the server detects that the user “bobsmith” has provided an incorrect password three times since his last log in, the server might decide that the “bobsmith” account is the subject of a brute force attack and will disable it. The account may automatically reactivate after 30 minutes, or the user might have to contact the site administrator to have the account reactivated.

In either case, automatically disabling user accounts is a poor security mechanism to fight a dictionary attack. In the first place, by disabling accounts, the system has traded an authentication-evasion vulnerability for a denial-of-service vulnerability. If an attacker can disable an account by incorrectly guessing its password three times every 30 minutes, he can effectively prevent that user from ever accessing the system. Imagine how damaging a dictionary attack could be if it were used against an administrative account.

In the second place, locking out accounts is ineffective against a brute force attack because this technique assumes that the attacker is keeping the user name constant and varying the password. What if the attacker instead kept the password constant and varied the user name? We already know that a large percentage of users use common passwords like “password.” A hacker using a dictionary attack could try “password” for each of the users in his user name list, which would not only have a high chance of success, but would also evade the account lockout logic. An attacker could make thousands of log-in attempts, and even if every one of them failed, the system will only register one incorrect log in per account.

A better strategy for blocking any brute force attack is to incrementally delay the page response after failed log-in attempts. After the first failed log-in attempt, for example, the response would be delayed by 1 second. After the second failed attempt, the response would be delayed by 2 seconds, and so on. A one-, two-, or even six-second delay is probably not going to bother a human user too seriously. Certainly he will find it less irritating than having to wait 30 minutes for his account to reactivate because he accidentally left his caps lock key on.

On the other hand, an incrementing delay can completely defeat an automated tool being used for a brute force attack. Assuming the tool could normally make 10 requests per second, the time it would take to make one thousand requests would jump from 2 minutes to five days. This pretty much renders the brute force attack tool useless. An incrementing delay also solves the problem of the attacker holding the password constant and varying the user name. Since the system tracks failed log in attempts on a user session basis and not an authentication credential basis, the delay logic cannot be bypassed this way.

There is one serious shortcoming to the incrementing delay approach: State must be kept in order to record the number of failed log-in attempts by the current user. The dictionary attack tool can be set up to begin a new session on every request by never sending a session identification token to the server. In this situation, the server will not be able to track the number of failed log ins, and the delay will not be properly applied. It is possible to track a user from his IP address instead of his session token, but this technique has problems as well. Sometimes multiple users share a single IP address, and sometimes a single user can change IP addresses between requests. While the incrementing delay technique is not perfect, in many cases it is a better solution to fighting a dictionary attack than the widely used practice of locking out accounts after failed log in attempts.

Finally, it is important to create appropriate error messages in response to failed log-in attempts. Many Web sites inadvertently aid hackers by providing overly helpful error messages. Consider the difference between the messages “User ID not found” and “Incorrect password.” These messages give a lot of information to a potential attacker. “User ID not found” tells the hacker that the user he is trying to determine via brute force attack does not exist in the system. There is no point in continuing to try different passwords for this user name. He can continue on to the next user name in the list, saving himself thousands of useless requests and hours of time.

On the other hand, “Incorrect password” tells him that the user name he has tried with his dictionary attack does exist, but that the password is wrong. Now he knows that he has a potential victim and can focus his efforts on breaking that user’s password.

It is much safer for the application to respond with an ambiguous message like “Incorrect user name or password” when a log- in attempt fails. There is no way to tell from this error which part of the credential was invalid. Therefore, there are no clues that a hacker can obtain from this error that can help him reduce his workload and break the system faster.

In conclusion, sometimes old, boring attacks can work just as well as the new, exciting ones. Low-tech as it might be, a brute force attack can be very effective at compromising your Web application unless proper defenses are used. The first and foremost method of defeating a brute force attack is to require all users to choose a strong password. Passwords should be required to contain at least seven characters, with mixed upper- and lower-case letters, numbers and punctuation. Also, consider implementing an incrementing response delay routine in your application in place of an automatic account lockout.

Finally, be sure to display nondescript, ambiguous log-in failure messages such as “Invalid user name or password.” Messages like this provide no extra information about the system that a hacker using a dictionary attack can take advantage of to lighten his workload.

Following these guidelines will help you protect your application and your users from the brutes of the world.

Learn more