By the book: How to prevent a dictionary attack

SPI Dynamics –

If your Web site (or a portion of it) requires a user to login and be authenticated, then the odds are good that a hacker has tried to break into it. Here's why: Hackers are well aware that anything kept under lock and key is probably worth stealing. In terms of processing power, it is expensive for a Web site to require authentication, so it is usually only required when a site stores valuable private information. Corporate intranet sites can contain confidential data such as project plans and customer lists. E-commerce sites often store users' email 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 username and password combination containing SQL code to the login form, an attacker can often trick the server into granting him unauthorized access. These types of attacks are creative, elegant, and effective and they get a lot of attention. But 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).

The brute force attack is about as uncomplicated and low-tech as Web application hacking gets. The attacker simply guesses username and password combinations until he finds one that works. It may seem like a brute force attack is unlikely to ever succeed. After all, what are the odds of someone randomly guessing a valid username and password combination? Surprisingly, the odds for a brute force attack can be quite good if a site is not properly configured.

Don't be lazy. Choose a password carefully!

Users often create very simple passwords like "password," "1234," their spouse's name, or their favorite sports team that are easy for the user to remember, but unfortunately 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 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, 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 username 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.

Sidestepping a dictionary attack with username selection

Of course, a password is only half of the required login credential. A username is also required. While it is less likely that a dictionary word would be used as a username, there are still some common usernames that hackers are certain to try with a brute force attack. First among these are "admin" and "administrator." These names are especially dangerous because 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.

Countering a brute force attack with a strong password policy

Here are some guidelines for creating a strong password:

  • 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 characters long and can include upper case, lower case, 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.

Other defensive strategies - and why they don't sork

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 against a dictionary attack is to automatically disable an account after a certain number of failed login attempts. 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.

By disabling user 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.

Furthermore, locking out accounts is ineffective against a brute force attack because this technique assumes that the attacker is keeping the username constant and varying the password. What if the attacker instead kept the password constant and varied the username? A hacker using a dictionary attack could try the same username for each of the users in his 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 login attempts, and even if every one of them failed, the system would only register one incorrect login per account.

A better defense: Incremental delay

A better strategy for blocking a brute force attack is to incrementally delay the page response after failed login attempts. After the first failed login attempt, for example, the response would be delayed by one second. After the second failed attempt, the response would be delayed by two seconds, and so on. A one-, two-, or even six-second delay is probably not going to bother a human user too muchm but it can completely defeat an automated tool. Assuming the tool could normally make ten requests per second, the time it would take to make one thousand requests would jump from two minutes to five days. An incrementing delay also solves the problem of the attacker holding the password constant and varying the username. Since the system tracks failed login attempts on a user session basis and not an authentication credential basis, the delay logic can't 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 login 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 logins, 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.

Carefully word your error messages

Finally, it is important to create appropriate error messages in response to failed login 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 username. He can continue on to the next username in the list, saving himself thousands of useless requests and hours of time. On the other hand, "Incorrect password" tells him that the username 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 username or password" when a login attempt fails. There is no way to tell from this error which part of the credential was invalid.


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 best method of defeating a brute force attack is to require all users to choose a strong password. 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 login failure messages that provide a hacker with no extra information about the system. Following these guidelines will help you protect your application and your users from the brutes of the world.

The ideas expressed in this article are solely those of the author and do not necessarily reflect the opinions of

This story, "By the book: How to prevent a dictionary attack" was originally published by ITworld.


Copyright © 2007 IDG Communications, Inc.

It’s time to break the ChatGPT habit
Shop Tech Products at Amazon