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:
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
To continue reading for free, register below or login
To read more you must become a member of SearchSoftwareQuality.com
permutations and combinations required will be less:
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.
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:
Password page
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
