How to guarantee bad passwords

Getting users to choose good passwords and not write them down is always a challenge. It's a tradeoff - if you make the requirements too loose, then an attacker can guess the password. Make it too complex, and users have to write them down. The rules should be proportional to the sensitivity of the data that's accessible - read-only access to a newspaper shouldn't require as strong a password as financial or health information.

In the "too loose" category, the extreme case I've run into was a web site used for storing personnel information - which should have had relatively strong requirements - that required a two character password. No quality restrictions, no frequency of changes, nothing. Bad choice.

Today, I ran into the other end of the spectrum. A site that requires passwords that:
* have a minimum length of 9 characters
* must contain two upper and two lower case characters
* must contain two digits and two special characters
* must be different from the last 9 passwords you've used
* must not contain a single quote

But the kicker: passwords may not contain any word of two letters or more. That's apparently determined (as best as I can tell through trial and error) by comparing every substring to a dictionary. So a password like 97to$%ABC isn't acceptable, because "to" is a word. And 3-5zq?jbeLN isn't valid either, because "be" is a word. Presumably a1b2c3d4e5** would be a valid password, though. (I didn't try that one.)

Oh, and the password expires every 60 days, so just about when you've come up with something that matches their criteria, it's time to change again.

Now granted this site has some sensitive information, but wouldn't it make more sense to use certificate-based authentication, which is far harder to attack in a brute force manner than passwords? (Assuming, that is, that you're not using certificates with MD5 signatures.)

I'd bet that 90% of their users have the passwords written down.