There's a scene in the new Hangover movie (hat tip: Matt M) where one of the characters is reading off the credentials needed by another to log into some online service.
Mr. Chow: "Password?"
Alan: "Bologona...One"
Phil: "Your password is bologna one?"
Mr. Chow: "Well, it used to be just bologna, now they make you add a nuuuhhhmber!"
Guy:"****ing annoying"
And there, folks, is the 4-second distillation of so much of what is wrong with information security today. The users put up with the controls, but find them absurd and annoying. They disrespect the controls, so they ignore them in practice. Frankly, it's difficult to blame them. Logically, the combination of controls we throw at our users doesn't make sense. Let's look at the most common ones and then come back around to a call to action.
minimum length: this control, which most places usually set to at least "8", as far as I can tell, originates from a 1972 paper in Advances in Computers, Vol. 12. This paper asserts that, to achieve a 1:10,000 probability that a password will be cracked at the maximum transmission rate of an attacker's line (estimated to be 300 characters per minute, or approximately 40 baud) using a 26-character alphabet, the password needs to be at least 8 characters long. Nowadays, the logical answer to brute-force attacks depends on whether they're online or offline. For online attacks, locking the account (or slowing down the line) upon detecting password guessing is considerably more effective; for offline attacks, rainbow tables and GPU-powered cracking tools have demonstrated that 8 characters isn't nearly long enough.
complexity: this is an example of a good idea taken too far, and in the wrong direction. We infosec folks understand that the space of possible passwords an attacker has to guess grows as x^y, where x is the space of possible characters used and y is the length of the password. Sure, 27^y (all lowercase characters plus spaces) doesn't grow nearly as quickly as 95^y grows (all characters you can type on a standard keyboard). The problem is that most humans' ability to memorize long, complex strings either runs out at y=5 or we naturally limit ourselves to a smaller number of choices than 95. Mr. Chow's password wasn't "bologna6", it was "bologna1." On the other hand, we're much more likely to remember three or four words strung together, so we can get better mileage out of large values of y in 27^y, as Thomas Baekdal argues so effectively in his excellent Usability of Passwords post.
periodic, forced change: again, we need to look at our threat model. If your attacker can eavesdrop on your password, this control adds no value. If your attacker can capture your keystrokes, or is a rogue sysadmin, this control adds no value. If your attacker is brute-forcing your password online, this control adds little value, certainly compared to intruder lockout. The only time this control adds value is if your attacker has an offline copy of your password database and it's a race between the user changing the password and the attacker cracking it. Per some of the articles quoted above, modern computing allows the bad guys to crack all but the longest or most absurdly complex passwords in hours or days; we typically give our users at least 30 days before changing their passwords, often longer. This is not a good race to try to win if we're the InfoSec folks.
So now it's time to bring it back to Mr. Chow, our prototypical user. We tell him that he has to have a complex password and change it regularly because, if he doesn't, Al Qaeda wins. There are at least two problems with this approach. One is that, if the adversary is well-funded and determined like Al Qaeda, they will bypass these controls through a side channel; targeted malware comes immediately to mind. The other problem is that we are creating incentives for everyone to behave badly. We force users to add a number, and they'll just keep incrementing the number. That forces us to escalate: we have the system remember what password they chose last time and force them to change multiple characters, or we prevent them from using dictionary words, or we don't let them tack the number onto the end or capitalize the first letter. Then, not only do they have the incentive to write their password down for fear of forgetting and locking themselves out, our system also has to store some additional information that may assist the offline attacker.
Here's my proposal to the InfoSec community: if we're serious about protecting something, let's station restrict it, or require two-factor authentication, preferably both. If we're protecting something because not protecting it at all would be outrageous, let's give our users a break on the silly controls and apply a reasonable threat model. Do the cheap, simple easy stuff every time: lock out intruders, encrypt (technically, salt and hash) at rest, encrypt in transit. This effectively takes care of all but your rogue sysadmin and your keystroke logger (which is, really, just an extreme, long-distance case of the shoulder-surfer or passerby who notices the stickie on the monitor); no amount of regular password changing or content complexity defeats those threats. If we have to convince someone that a lucky guess won't defeat our controls, let's pick a password entropy level that we can live with and make sure our users exceed it. Let's also help them by providing visual password strength meters when they're enrolling or changing their passwords. Maybe, just maybe, our users will give us a little credit for treating them with respect and not trying to convince them that "f@%K!7_)" is a better password than "good times van".
Aside to MSFT: if your nifty online password strength checker tool already knows that "Bologna1" is a weak password, why don't you use your position of power to get people to stop thinking that the "3 out of 4" test against {alpha_lower, alpha_upper, numeric, !alphanumeric} is some sort of gold standard? Thanks.
Aside to PCI: something you know is a piece of trivia; something only you know is a password. Apply similar logic to something you have (see The sketchy ex-roommate test) and something you are. Thanks.