Restrictive Password Rules Are Bad, mmmmk?

There are all kinds of things that a discussion of password security could go into, for example:

• Why passwords need to be stored properly on the data system
• How does a mixture of password implementation policies protect the system from account hacks?
• The risks of rainbow tables and cloud computing

None of those topics are the topic of this discussion, but they are all integral to the security of your password authentication system.  Never mind that secondary authentication via tokens or biometrics are really the way to go if you want system security.  Lots of enterprises and most Internet services are still stuck in the userid/password authentication age.  In order to understand the topic that I'd like to discuss, it is important that all of the above

• Why restricting your users to seemingly arbitrary or complex rules actually lessens the strength of your password system.

The prevailing argument is that users will not create complex passwords unless they are forced to do so.  Because of this, users must be forced to create passwords that will not fall prey to 'dictionary' attacks against the account.  And this argument has some merit.  After all, even with the proper policies in place, if the user selects a password of 'password', their account will fall prey to someone trying to break in.

However, some have taken the step of implementing password rules to a level that it is actually damaging to their password system, and they may not realize it.  After all, the password 'password' may no longer be the first most used password on their system because it isn't allowed, but the password "1234qwer!@#$QWER" is probably at the top of any good hackers list, and is allowed by even the most restrictive of password rule systems.  Just because this second data string doesn't make sense to us doesn't give it any magical properties of being more secure than the 'password' password.  Nay, for a computer, the second password has more patterns in it that the first ever did.

Recognizing a bad password is not something that is easily understood (although it's not an impossible task for an AI engine), but what the system administrator needs to know is that their password rules need to be in  place that will make it as unlikely as possible that the user would create such an easily guessed monstrosity, and that the password the user creates will be both secure and easy to remember.  This means both having restrictions (to ensure that single words and '123456789' are not used as passwords), and having reasonable and easy to meet restrictions that the user will be able to come up with a good password when asked.  Once the restrictions get too tight, the user is going to logically process the rules into a pattern because they cannot easily come up with something that meets the restrictions.

Another problem is restricting the size of a password field is something that should never be done.  Limiting a user to only 8, 10, 12, 14 characters is entirely arbitrary, and speaks to improperly implemented password storage systems.  If you have a maximum limitation on your password, it screams to the world that you are storing the password either in clear-text in a data system, or something that any hobbyist cryptographer could crack open (rot13?  XOR data field?).  If you properly implement password storage as one-way salted hashes in your system then it won't matter how long the user password entry is.  You should give them more than enough room to enter any reasonable string - arbitrarily, say 256 characters, so you can size the field and protect from buffer overflows, but you get the idea.

What about complexity requirements?  They need to be simple to understand, and should be free of 'systemic' requirements.  You should not forbid the use of any valid entry character.  This may mean even allowing the entry of such no-no's as ',@ and " - if you don't accept these characters, you're again telling the world that you're doing something with the password you shouldn't be doing, like storing them in a database.  Complexity should be simple to follow and easy to come up with something useful...perhaps a restriction to use at least one character from each of the sets:   UPPERCASE-LETTERS, LOWERCASE-LETTERS, SPECIAL-CHARACTERS, NUMBERS.  This is easy enough to follow just by using natural passwords like I*Hate%Passwords.

The more restrictive your rules, the more likely your users are to rebel by using something systematic (QWERTY12345qwerty!@#$%).  If you frustrate your users, they'll just be looking for a way to get around your 'stupid rules' rather than be a partner in protecting their information.  You'd much rather get someone to be inventive (like: Rosemary'sBaby1997).  This password may seem simple to you and me, but it's because our minds are tuned to pick up and categorize the symbols in the password.  For someone who doesn't know the password, it's going to take a LOT of guessing to get that password from the system.

And if you're properly hashing, salting and securing your password (shadow) file - a dictionary attack is going to have a hard time guessing that password at 3 allowable guesses per hour (between lockout).

Less focus should be spent on protecting yourself from system administrator staff who may have access to the secure password hashes and salt.  If they want to get into your system, they have much more direct ways to impersonate users than pulling down that data and running computations against it.  Instead, the focus on password security needs to be:

• Implement proper password storage and validation
• Partner with the user - don't piss them off
• Implement password and account policies that don't enable hackers to use your own CPU power to attack your accounts. (Account locking after so many guesses, only allow single sessions when feasible - session timeouts, disable session re-use, etc...)
• Log and monitor logs for suspicious activity
• Warn users when their accounts have been used (and ask them to validate the usage)