What is a dictionary attack?
There are a lot of tools that can automate the login process by submitting authentication credentials to a web applications. With a bit of effort, anyone can create such a script. How does this affect you and the security of your web applications? In the hands of a malicious person, this can be a dangerous weapon. With a list of user-ids and passwords, this person can try to guess a valid user’s credentials and login. Once logged in, the application will assume that this person is the valid user that the credentials belong to and will allow access to resources (links with the application, documents, reports, etc).
There are some steps that an application take to prevent this sort of attack.
Restricting login attempts
The first one is restricting the number of consecutive login attempts, usually between 3 and 5. After the specified number of unsuccessful attempts, the application will not allow any more attempts from that particular IP address for a specific time period. This method has some drawbacks. When a lot of users try to access the application from behind a single gateway (such as from within one company), there is a possibility that legitimate users are locked out. Consider the following scenario with 2 users and an application that restricts users to 3 login attempts.
User 1 tries to login twice unsuccessfully.
User 2 then tries to login unsuccessfully once.
Now, both users will be locked out. One solution that immediately comes to mind is to increase the login attempt limit, say 10. That means an automated script can try 10 combinations before it will be locked out, which is less safe. This method is also vulnerable to distributed attacks where many computers are used in the attack.
In this method, the application delays the response to a login attempt. The delay itself can be a second or so. This amount of delay will not be visible to a human user, but will prevent a malicious user(human or automated) from checking a large number of creddentials. Another variation is to progressively increase the time delay. For instance, for the first 3 login attempts, the delay could be a second and then the delay increases to maybe 10 seconds.
This may not work when presented with an attack originating from several hundred computers at the same time.
Another solution is to perform a test that attempts to differentiate between a human and an automated script. One test that does this is called a Reverse Turing Test or CAPTCHA. This is a type of challenge-response test used to determine whether or not the user is human. A common type of CAPTCHA requires that the user type the letters of a distorted image, sometimes with the addition of an obscured sequence of letters or digits that appears on the screen. This method may be defeated by other automated tools.
These tests should satisfy the following criteria:
- Automated generation: It should be easy to generate many instances of the test in an automated way.
- Easy for humans: A generated test should be easy for human users to solve.
- Hard for machines: An automated adversary should not be able to answer the test correctly with a probability that is significantly better than guessing.
- Small probability of guessing the answer correctly: The probability that a random guess produces a correct answer to the test should be small. For example, a test that presents an image of a person and asks the viewer to type whether this is a male or a female would be insufficient, since there is a probability of 50% for guessing the correct answer.
Points to remember
The goal here is to make the expected cost for somebody to be successful with a dictionary attack so high that breaking into accounts does not make sense financially. In many cases, the above mentioned methods, individually or in combination, should satisfy the security requirements.