Targeted password cracking - Proof of concept

This is a proof of concept to exploit the registration functionality of a website to build targeted password cracking engine. I am using Ajax to automatically detect the parameters which are submitted for a successful password and automatically resubmitting the modified passwords. Of course other technologies can be used for the same.

I think I can safely assume that by now we all understand the need of a strong password handling mechanism, which starts from a strong password policy. In the password policy we define the rules for the password selected by the user to login to their account. The idea is to make them stronger so that they are not easily guessed and more importantly, the password cracking tools cannot break them easily. Some websites have stricter password policy as compared to others but more often then not, the website owners also care about the customers as stronger passwords are difficult to remember. The stronger the password is, the chances are that the user might forget it especially if it is not something you use every day. Many companies also define the password policy keeping in mind many criteria, in which two of the main criteria are:

1. From the support perspective, password reset call volume might increase. (Not everyone has a online password reset functionality)
2. Inconvenience to the user.

There could be more depending on the company but these two are often brought up by the product team.

With the increase in SQL injection attack and XSS attack, many security professionals implement character filtering on anything that comes from the client. It could be blacklist character filtering (do not allow potentially harmful characters) or whitelist character filtering (only allow valid characters) depending on how a security professional or architect wants to approach it. For the sake of the argument let’s say the architects apply these filters globally which means these filters are implemented for passwords as well, further restricting the character set for the password selection. This is where we have to be extremely careful. If an application, filters characters for password fields as well on top of the security policy then you are limiting the character set for passwords and this could be reverse engineered to make intelligent password cracking tools.

Let’s take a look at how it can be done and what we can do to protect from it. To start with, we need to find out the following:

1. The minimum number of characters that are allowed for a password field?
2. Should it start or end with a capital letter?
3. The minimum number of capital letters required?
4. The minimum number of digits required?
5. Should it start or end with a digit?
6. What characters are not allowed (for example “<,>,#,&,\” etc)?

If we can find the answers to the above mentioned question then we can fine tune the password cracking tool to follow those rules as a result the number of permutations and combinations required will be less.


If we start by successfully registering a password on a website and then reverse engineer it to find what is allowed and what is not allowed. For example, let’s say we can successfully register with a password which contains 8 characters and starts with a capital letter and ends with a numeric (Say “Abcdefg1”) and rest all the characters are lower case alphabets. Assuming the registration is successful, we’ll start working backwards and find out what characters are filtered and what characters are required in what sequence.

1. Remove one character from the middle of the password keeping the first character (Capital letter) and the last character (Digit) intact. Use this password to register and keep reducing by one character from the middle until you get error.

2. Register with a password with one character removed from the middle of the original password, keeping the first character (Capital letter) and the last character (Digit) intact. Keep reducing by one character but keep the capital letter and number until it gives error. This way we can determine the minimum length of the password for the application. For example, “Abcdef1”, “Abcde1”, “Abcd1”, etc

3. Move the capital letter from the beginning to some other part of the password keeping the number and minimum number of characters allowed and see if it gives error. This will tell you if the password requires you to start with a capital letter or you can have it anywhere within the password. For example, “aBcdefg1”.

4. Select a password with minimum number of characters allowed and no capital letter and one numeric. If it doesn’t give any error that means capital numbers are not allowed. For example, “abcdefg1”

5. Select a password with no numeric character with one capital letter into it. If it doesn’t give any error then numeric is optional.

6. Replace a non numeric and non capital letter of the password with a character from a list of other characters (for example, %, ~, !, @, #, $, %, ^, &, *, <, > and so on). Replace the character one at a time and check if you get any error. If you get an error that means the character is not allowed.

By performing the above mentioned steps you can find out what characters are not allowed by the application and hence you can remove those characters in your password cracking tool and further set the rule for the characters allowed in certain order.

Now, if the application is filtering for blacklisted characters in password as well, then the list of characters not allowed will grow and will be favourable for the password cracking tool. By any chance if the application is doing whitelist filtering for passwords as well, then the characters actually allowed for passwords would be very limited and hence make it extremely easy for the password cracking tools.

The password is selected when a user is trying to register to the site. We don’t usually lockout the registration page after any number of unsuccessful attempts as we believe the user is trying to find the correct password combination. Some of the websites on their registration pages have captcha to ensure protection from bots but not many sites have that.

We can take certain steps to prevent us from this type of attack
Registration page

1. Implement a captcha. (though this is a tough one as it is a great inconvenience to the user but it does protects from automated attacks)

2. If we don’t filter the characters then there is a possibility of SQL injection attack. For that, we can hash the password before inserting into the SQL to store in the database (That is the general trend these days anyway) but we should be selective about what we filter and what we do not filter.

3. Put a delay of few seconds in every subsequent attempt. This is not a full proof solution but it definitely slow down the automated attacks.

4. Encourage the user to select stronger passwords by displaying how weak their password is on the registration page even though it is not enforced by a password policy.

Password page

1. Implement password lockouts. Reset the password after lockouts. The new password should not be same as the last password (at least)

2. Be selective about what you filter for the passwords.

3. Put a delay of few seconds in every subsequent attempt.

You can see the demo and download the code from Attack Labs

Explanation of the code can be viewed here