The password problem

Odds are good if you’ve reached this blog, you have an account on at least one website somewhere on the wild wild web. This account could be on a web application ranging from something as critical as a finical institution or your primary email account to something as trivial as your account on some random blog. I’ve got far too many to even be able to number, falling everywhere in between those two lines, and have created my fair share of passwords. Normally, this is the point where the blogger starts ranting about “longer passwords” or “use a passPHRASE” or “use special characters.” This time however, I’m pointing the finger at the application designers.

Originally, this post was going to be little more than my frustration with not being able to use passwords that I desired, due to restrictive requirements on applications. After gathering some data, to have a soap box to stand on, I realized that some of these “requirements” actually go beyond the surface level annoyance and actually affect the security of your account directly. Some of these applications go as far as to actually prevent you from using a secure password or reveal other weaknesses in the application’s design. I’m sure this isn’t a new find by any means, but some of the “requirements” I’ve seen are pretty outrageous. The most startling bit is a good majority of the examples I’ll be using in this post have come from accounts falling into that “critical” category.

Before I go on and discuss the various “vulnerabilities”, I’d like to note that the list below is definitely not a comprehensive list of all web application password vulnerabilities. Rather, everything below was gathered from requirement messages listed at the time of creating the password and other things I noticed while creating the account. The purpose of this list is to explain each issue, on both a technical and non-technical level, as well as to provide recommendations for end users encountering each. Examples used here are gathered from live, current web applications to represent the current issue as well as to provide real world examples as teaching tools for detection.

Restrictive Length

This was probably the most prevalent poor password requirement I came across, which is odd to me as I’ve never seen any reason to restrict a user’s password other than to require a minimum length. Despite this, we see the following types of messages all across the web:

Password must be 6 to 8 characters in length

Please enter a password that has a maximum length of 12 characters

By reducing limiting the number of characters a password can contain the number of possible passwords, the keyspace, is also reduced. This means that a malicious user who is either brute forcing the application or has obtained a copy of the hash and is cracking it has to check a smaller number of passwords.

Other than simply restricting length through verbose and obnoxious warnings, some developers will simply truncate your password. In some situations, this truncation happened through an html attribute defining the maximum length of the password creation field as well as the login field. This double-combo actually makes things worse as it may be some time before you notice that your 23 character password is being cut-off at 12 characters.

Restrictive Character Set

I can almost build a case for these requirements. Almost. I’ve spoken with developers who have restricted characters allowed in your password by the same rules they disallow characters for SQL injection blocking or cross site scripting prevention. In other cases, I’ve seen character sets reduced by case-insensitivity.

Contain no spaces or special characters (eg <, &, >, *, $, @)

No spaces or invalid symbols

Contain 6 to 8 characters – at least one letter and one number (not case sensitive)

In these examples you can see developers trying to limit their attack surface by preventing any sort of attack on their application through the password field. Where this argument breaks down is, a proper application should be one-way hashing the passwords. When the password is hashed these special characters are eliminated and thus rendered safe.

In the third example, you can see that the keyspace is reduced even further by removing 26 characters, either the upper or lower case letters. At the same time they have reduced the keyspace characters to 36, they’ve also limited password length on both the upper and lower end.The combination of these two restrictions effectively reduces the keyspace from 218,340,105,584,896 (8 characters, upper/lower-case, numbers) to 2,821,049,441,280 (6-8 characters, case insensitive, numbers), just over 1% of the password possibilities.

Defending yourself

In many cases, when you come upon a web application as inherently insecure as the ones listed above it’s probably best to simply walk away and not bother with it, however; there are cases where you may need to create and use and account. It’s possible to mitigate some of the risks of restrictive passwords by paying attention and adjusting your password accordingly.

Probably the greatest risk of the issues outlined above is the possibility of your password being compromised by another user. As it’s impossible to create a stronger password than the application will allow, this reduces our options drastically. I suggest creating a couple passwords and then group accounts into “security levels” based on their requirements. By having multiple passwords and using them on web applications with varying levels of security, you can ensure that a compromise due to one of these poor password policies is limited to a password only used on other such sites.

Detection is important because without it you aren’t able to correctly classify the security level of the application’s password policies. Beyond simply looking at the requirements listed, a complex password designed to trigger applications with poor password management to fail can be used to test the application.

#th!$iSaG<><>|)’test–p@ssword”!*

The password above can be used to test applications. By including common SQL injection characters, cross site scripting characters, upper/lower case, numbers, commonly denied symbols and a length of 33 characters  you can test the whole array of restrictions. Beyond simply testing the restrictions, it actively tests the application for SQL injection potential. The ‘ and ” characters included in the password are designed to trigger SQL errors if they are not handled (either by hashing or SQL character stripping.) An application that throws an error on this password should actually be considered significantly less secure.