Cenzic 232 Patent
Paid Advertising
web application security lab

Security policies weakens passwords

I’ve always been interested in passwords security, since I very first started in this industry, in 1995. Eleven years later, I am still doing research into passwords. Something has bothered me for the last year or two about passwords policies, however. I began looking into some of the more and less effective means to protect passwords a while back. Some of the more common ideas is that a password must be greater than a certain length, must contain more than just letters, etc… But what exactly does this mean from a brute force standpoint?

Well, let’s look at a typical brute force attack. Generally there are a few thousand or tens of thousands of common dictionary passwords “password” and common names “Jenny” along with a few common obvious non alpha passwords like “123456″. Once those fail (and they rarely do) they move onto less obvious enumeration. Let’s take a fairly standard unix password policy:

The password must be greater than 6 characters but less than 8. If you take the entire alpha and numeric set that is 36 chars times 2 (for lower and upper case). If you add in !@#$%^&*()-_=+[]{};’;”,.<>/?~` that’s another 30 chars minus @ and # because of their subtractive property on some older systems. Let’s just make it a round 64 chars total (that number may be different on international keyboards, but let’s just use this as an example).

So 64 chars with a password length of 6 - 8 chars. That means that there are between 90^6 (531,441,000,000) and 90^8 (4,304,672,100,000,000) combinations possible. Wow! Pretty impressive.

But now let’s start layering on some common security practices. Let’s remove all of the 100% alpha and 100% numeric (must contain at least one number and one letter). That’s between 26^6 (308,915,776) and 26^8 (208,827,064,576) for the letters and between 10^6 (1,000,000) and 10^8 (100,000,000) for numbers. Now let’s do something else I’ve seen on websites before, like convert everything to the same case (in case the poor user forgets the caps lock). Take your 36^6 (2,176,782,336) and 36^8 (2,821,109,907,456) which represents your upper case you are now effectively removing and subtract it as well.

In just a few small steps you’ve reduced the total number of items you have to search from between 531,441,000,000 for the lower end and 4,304,672,100,000,000 for the upper end and changed it into between 529,263,217,664 and 4,301,850,890,092,544. That’s about 1/10th of 1% of the total keyspace that is now irrelevant.

Now force the users to have many upper case and lower case and numbers and symbols, and make it so they can’t have any of the same chars as their username (yes, I’ve seen this in the real world on Hotmail), and you are talking about major degredation in the size of the possible keyspace. Sure 1/10th of 1% isn’t much, but this could point to larger issues the further you go with this.

/RSnake

6 Responses to “Security policies weakens passwords”

  1. Sarah Says:

    Yes, *bad* security policies weaken passwords; but good security policies (like have a password longer than 8 chars) can create stronger passwords. In an ideal world, best practice would be to have a minimal policy (minimum password length, use characters from the Windows-allowed 95-printable-char keyspace (plus [space], | and \) there are also many more newer systems out there than older systems so @ and # are also totally valid; or if you’re awesome and have some distro of linux, 128-char or the exciting 65,536 UTF-8 charspace; and then try to educate users as to why it’s a bad idea to use a word from the dictionary, or their username, or predictable string sequences like “qwerty”.

    Unless companies or services use proactive password checking to weed out easily guessed passwords from the beginning, there will always exist at least one person whose password is something like “password”. So, most crackers won’t have to worry about shifting out all those extra passwords that are named as “weak” by the security policy. Dictionary attacks can usually crack 20-35% of the passwords of a given set of passwords (see ; I have more links, but I haven’t gone through all of them yet) so just cycling through a cracker’s “dictionary” is enough to gain a foothold in a system.

    So, suffice to say, I disagree with your title.

  2. RSnake Says:

    That’s very true, Sarah, and thank you for posting. If you consider that some security policies actually can make you put into the space of longer passwords (and ultimately a higher keyspace), sure, in that case, I would agree that it could increase the keyspace making it effectively harder to brute force. The problem is, people are still people. So if you make them have a 100 char long password, chances are you’ll end up with a dictionary word that’s 5 chars long and then 95 “1’s” after it. Another bad policy that I see quite often is that the password must be all numbers. Well if your password was 8 chars and could be anything, you are talking about a rounding error of possible keyspace left after you force it all into chars… so length isn’t everything (despite what some people think). :)

    I’ll probably write some more about this soon, as I came across a good snippet of info in one of the books I’m pouring over, but MOST security policies I’ve seen actually reduce the keyspace, and in some, it’s nearly obliterated it. I agree with the statement that people will choose things like “password” but how is that really any more secure than making the password length greater than nine chars and the user picking “password1″? I’ve done quite a bit of actual password analysis on real world passwords, and I’ve got the say, the users will almost always pick the weakest password possible. In fact, I’ve actually been able to guess people’s password before, in only a few minutes of talking with them - it’s really that bad. Then add on prohibitive security policies and I can tell you with a high probability to avoid certain types of attacks, as they will be ineffective, and focus on other attacks.

    Keyspace is the critical issue. Let’s say you up your password length minimum to 8 chars as a requirement (let’s pretend that’s the only part of the policy that exists). Now I can tell you to focus that same dictionary attack but only look at words 8 chars or longer. Guess what, “password” is still 8 chars. If I built a password function into this site, and required that you have 8 chars, an upper and lower case char, and at least one special char, I bet you a good percentage of passwords would be “Ha.ckers.org”. It’s almost silly.

    But in most cases, I agree with you, increasing keyspace, and increasing the types of chars availible to use as passwords will ultimately help your resistance to brute force. It’s just that not many sites actually do that. But to your point, I should have been more accurate in my title and named it, “Security Policies Can Weaken Passwords”. My bad.

  3. Sarah Says:

    Anytime :) Hm, my link didn’t go through. Didn’t notice that the other day, sry. It should be: http://www.smat.us/sanity/pwdilemma.html - maybe putting it between less & greater than signs made it go away.

    Numbers only? Crazy. I thought that was perhaps just pins. I haven’t been in the field too long, so I’ve only seen the few university and generic policies that seemed (on the surface) to be ok.

    Can I ask what book?

    Cheers,
    Sarah

  4. RSnake Says:

    Yah, the book is Hacking Web Applications Exposed (Second Edition). It’s a re-write of the first. I’ll go into it more in another post, but yes, there are definitely situations where the password policy makes you use nothing but numbers (or all lowercase letters). I have a few concrete examples, that I’ll put in my post at a later date.

  5. ha.ckers.org web application security lab - Archive » Password Policies Continued Says:

    […] Last month Sarah and I had a discussion regarding weak password policies. Sarah mentioned that there are ways to improve password security by using policies, and I argued that that is true only in terms of time to crack, and no in terms of actual keyspace in many of the cases I have seen. I really feel like I should give more information on this because it’s a complicated issue and I’ve recently run into a few great examples of this. But before I get started there was an email I recieved that’s probably worth a read: Hello, I’ve been visiting your site for a few months now, and love your ability to constantly come up with new security issues. A few weeks (maybe a month), you posted a message about Facebook being harvested for data by 2 individuals. I followed the link, and copied the master file they created. At first I had the semi-malicious intent to enter users information (mostly if they had Myspace accounts) so I could advertise a bit, or get a laugh. I ended up deciding to pursue checking passwords for statistical purposes on password issues. I wrote a program to run through the 1,280 email addresses listed on the file, request a search on Myspace to detect if they were users, found 840 Myspace users out of the list, and then attempted to login “by hand”. A large portion of the time the password for their Myspace was the same as their email, or if it wasn’t, and I could access the email, I could simply request the password. I had the intent to go through all of them, and then generate a page for my site (without their passwords) listing wiether or not access was easily obtained to their Myspace, their email, and if their email passsword was the same as their Myspace password. I’m not a Myspace user, but I figured it’s a very large network with millions of “noobs”. Perhaps you should address these password concerns on your site. A good portion of passwords were birthdays, “password”, years, or parts of their email address. If I weren’t afraid to get caught doing this (because proxies were taking too long so I did it without one), I’d most likely go through all of them, and write out the statistics. […]

  6. dave Says:

    Hi,
    On a similar note, I have a real issue with minimum password lifetimes and their relation to number of uses.

    Lets say you set your password lifetime policy at 90 days, after this you need to change your password.
    For something that you use every day e.g. your email then this is fine you may well use that password 90 times, so it is quickly committed to memory.
    However let’s say the password was for your credit card statements. At this stage you are likely to check that, say, once a month. At which point you only get 3 usages meaning you are more likely to put the password on a postit and stick it to your monitor.

    The crux of my point here is that absolute (e.g. always 90 days) password lifetimes are not necessarily best practice in all applications and in many situations may make the password more likely to be written down.