Yesterday, I wrote about stupid password rules and why they don’t matter for banks. Serendipitously, right after I published that post I came across an old Coding Horror post on stupid password rules. It’s a long and righteous rant on the infuriating, nonsensical password rules that confuse the less technically sophisticated leading them to seek workarounds that are less secure. At the same time, they frustrate the ideal user who employs a password manager to generate the long, random passwords that are more secure than anything the rules could provide.
Atwood doesn’t subscribe to the Irreal rule that any restriction is a sign of weakness. He divides password rules into two classes: those that you tell the users about before they attempt to choose one and those you apply as a sanity check after the a password is chosen.
There’s one rule in the first class: passwords must exceed a minimum length. What that minimum length is will vary according to the application you’re protecting and the environment you’re working in. Even if passwords are salted and hashed, a stupid password like abc is still easy to discover. A long password is effectively safe from brute forcing even with an offline attack.
The rules in the second class get rid of obvious passwords that any attacker will try. They include things like the user’s login ID, the user’s email address, and perhaps any password on one of the lists of most commonly used passwords that appear every year. You can read Atwood’s post to see the exact rules in the second class.
Of course, the only sensible thing to do is to use a password manager to generate long, random passwords. At least if the site will let you.