A recent client utilized some password controls (which are good) in ways we’d never seen before (which is bad).
The first thing that stood out was the length requirements. There was a minimum length of seven, and a maximum length of 8. The minimum was okay, provided additional controls enhanced it, but the max of 8 just seemed strange. It drastically cuts the available pool of passwords, for one.
For example, the password list we use contains (at the moment) 322,431 passwords, ranging from a length of zero to a length of 24. There’s only five passwords at 24, but they’re there. Note that random creations are not included, this is just a set of likely passwords, not all possible passwords. Unfortunately, when you restrict that to 7 or 8 characters the entire set contains only 80,610, a reduction of around 75%. Theoretically, that means during testing, we miss 75% of target accounts. Realistically, 7 and 8 character passwords are more common than many other possibilities, and other password controls, like minimum length, mean the smaller passwords don’t matter anyhow, so the real reduction in correct password guesses will not be as harsh as 75%. At any rate, restricting maximum length is idiocy; the only justification for such a policy is machine limits and a need to break in. Otherwise, if a user wants a 24 character password, let them have it.
Restricting complexity is also a fundamental control flaw. If your users are given the choice between making passwords that look like “ricky” or making passwords that look like “Ricky@Ches”, they are in large numbers going to opt for “ricky”. The math here is quite simple. The single set of lower case characters numbers 24. If you simply add an upper case requirement, you effectively double your possible key values. If you add in numbers, you gain another 10, and special characters can add another 29 (US Keyboard), or even more if you allow non-printing characters, up to 254. More realistically, a complete expected set of characters means 24+24+10+29, or 87 possible key character values. 87 is better than 24, by more 3X.
Repeatability controls are put in place so users don’t keep using the same password. This can mean not being allowed to use the same password until some time has passed or a certain number of changes have occurred. When implemented poorly, this allows very dedicated users to change their password multiple times in a row until the requirement is satisfied, and then return to using their original password, circumventing the logic and reducing the effectiveness of the control.
Intelligence requirements involve more logic to restrict obvious or encoded passwords. This can become complicated, such as restricting the use of date based encoding (using a date in the password), or simple, such as not permitting the 1000 most common passwords to be used. Each rule increases the amount of processing, but lowers the likelihood of a password failure.
There are other controls, but these are among the simplest and most common. Failing to enact one isn’t a catastrophe (with the exception of length), but failure to enact all of them is a recipe for disaster.