Password Complexity Rules

A Consumer Reports blogger has been taking Facebook to task for allowing certain dictionary words to be used as passwords (he found 20 of them). I can't confirm that Facebook actually forbids the use of dictionary words like the blogger claims. The signup page did not reject the word "animal" when I tried it, and their password strength FAQ does not state that dictionary words are banned.

The flak got me to thinking about password complexity rules in general. It needs to be evaluated when assessing the security posture of a web application. I see huge variety in the password rules that are being used. That's not the problem. It makes sense that highly sensitive applications, such as financial or governmental, should enforce stricter requirements. The problem I see is that the password rules simply aren't strong enough, ever. Identifying this weakness calls for a manual test or a code review. It is not something a web app scanner like WebInspect or AppScan would flag. Maybe that's part of the problem.

Below are the password rules I normally recommend for Internet-facing web applications.

• Minimum password length of 7
• Allow passwords to be 50 characters or more in length
• Require at least one uppercase letter
• Require at least one lowercase letter
• Require at least one number
• Allow special characters
• Do not allow any part of username to appear in the password
• Do not allow the user's first or last name to appear in the password
• Do not allow any form of the word “password”
• Do not allow the same character three or more times in succession

Notice there is nothing about banning dictionary words (other than a number being required). Applications can mitigate that particular risk by using an account lockout mechanism to prevent automated password guessing. Also, it probably goes without saying, but passwords should be case sensitive.

Please let me know if you have any other suggestions on this subject!