By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
|Anurag Agarwal, CISSP, senior application security consultant|
I think I can safely assume that by now we all understand the need for a strong password handling mechanism, which starts with a strong password policy. In the password policy we define the rules for user login passwords. The idea is to make them stronger so that they aren't easily guessed and more important, that password cracking tools can't break them easily. But often Web site owners also care about the customers and their ability to remember passwords, as stronger passwords are difficult to recall. The stronger the password is, the greater the chance that the user will forget it -- especially if it isn't something used every day.
Many companies also define the password policy keeping in mind many criteria, including the following:
- From the support perspective, password reset call volume might increase. (Not everyone has an online password reset functionality.)
- Inconvenience to the user.
There could be more depending on the company, but those two are often brought up by the product team.
With the increase in SQL injection and cross-site scripting (XSS) attacks, 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 (allow only valid characters) depending on how a security professional or architect wants to approach it.
For the sake of argument, let's say the architects apply these filters globally. That means these filters are implemented for passwords, 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 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 can be done to guard against it.
If you can find out the following, then you can fine-tune the password cracking tool to follow those rules as a result the number of permutations and combinations required will be less:
- The minimum number of characters that are allowed for a password field
- Whether it starts or ends with a capital letter
- The minimum number of capital letters required
- The minimum number of digits required
- Whether it starts or ends with a digit?
- What characters are not allowed (for example "<,>,#,&,\" )
Let's start by successfully registering a password on a Web site and then reverse-engineerng it to find out what is allowed and not allowed. For example, say you can successfully register with a password that contains eight characters, starts with a capital letter, ends with a numeric (Say "Abcdefg1") and the rest of the characters are lowercase letters. Assuming the registration is successful, you can start working backward and find out what characters are filtered, what characters are required and in what sequence.
- 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 an error.
- 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 an error. This way you can determine the minimum length of the password for the application. Example: "Abcdef1", "Abcde1", "Abcd1", etc.
- 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 an error. This will tell you if the password requires you to start with a capital letter or if you can have it anywhere within the password. Example: "aBcdefg1".
- Select a password with the minimum number of characters allowed and no capital letter and one numeric. If it doesn't give an error, then capital numbers aren't allowed. Example: "abcdefg1".
- Select a password with no numeric character and with one capital letter in it. If it doesn't give an error, then numeric is optional.
- Replace a non-numeric and non-capital letter of the password with a character from a list of other characters (e.g., %, ~, !, @, #, $, %, ^, &, *, <, > and so on). Replace the character one at a time and see if you get an error. If you get an error, then the character is not allowed.
By performing the above-mentioned steps, a person can find out what characters are not allowed by the application and then remove those characters in his password cracking tool and further set the rule for the characters allowed in certain order.
If the application filters for blacklisted characters in passwords as well, then the list of characters not allowed will grow and will be favorable for the password cracking tool. If the application does whitelist filtering for passwords as well, then the characters allowed for passwords would be very limited and would 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 because we believe the user is trying to find the correct password combination. Some Web sites' registration pages have captcha to ensure protection from bots, but there aren't many.
How to prevent this type of attack
You can take certain steps to protect us from this type of attack:
- Registration page
- Implement a captcha. (This is a tough one because it is a great inconvenience to the user, but it does protect from automated attacks.)
- If you don't filter the characters, then injection attacks such as SQL injection are possible. There are various other steps you can take to protect from SQL injection, including hashing the password before inserting into the SQL to store in the database. (That is the general trend these days anyway.) But you also need to be selective about what you filter and what you do not filter for in passwords.
- Put a delay of few seconds in every subsequent attempt. This is not a foolproof solution, but it definitely slows down the automated attacks.
- Encourage users 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
- Implement password lockouts. Reset the password after lockouts. The new password should not be same as the last password (at least)
- Be selective about what you filter for in passwords.
- Put a delay of few seconds in every subsequent attempt.
Visit attacklabs.com to view the demo and download the code.
About the author: Anurag Agarwal, CISSP, is a senior application security consultant providing expertise on secure development lifecycle and vulnerability assessment. He also manages attacklabs.com and myappsecurity.com.
Reader Feedback: Share your comments on this article