I'm surprised that Robert Graham, who is not ignorant of computer security, has mired his password recommendations in the 1980s. These are the same weak recommendations your Unix manuals would have given you 10 years ago.<p>What you should be doing is using bcrypt, tuned to take several hundred milliseconds per crypt. /usr/share/dict/words --- a pitiful dictionary --- with even the most basic set of permutations will take <i>weeks</i> to test a <i>single password</i> under this regime. Bcrypt is free and available for every major web platform. I didn't write it; the guys who did, David Mazieres and Niels Provos, are much smarter than me.<p>Computer science has solved the brute force problem on passwords, and we should stop dithering and adopt the solution.
<i>The second thing is to fix the password problem. They should force users to create more complex passwords when they log in.</i><p>Seen from a security perspective this adds to the overall security of the site, however most users simply find an easy password that fits the bill. blink182, 123456qwerty, qwerty! - which is almost as easy to bruteforce or keep in a rainbow table as normal dictionaries.<p>You should be aware, however, that password requirements detract from the user experience. When users pick a password for a new account they are at the most crucial part of a website: The sign-up. This is where you can lose people that were otherwise ready to sign up.<p>So it's a trade-off. If your site holds credit card numbers, or other vital information a certain minimum requirement for passwords is certainly in place, but if your site is something like HN, where no valuable information is held, you should probably just let users pick whatever password they like. Worst case they will lose a few comments and some karma.
Thanks for posting the link. I found this particular tidbit especially useful:<p>"The first is to create 'canary' accounts. Create accounts that have e-mail addresses, like "something-really-long-xyz-123@gmail.com". This account is not going to get any spam e-mail. When it does get its first spam, you'll know that it came from your database."
The original (first person) story is here, but the erratasec post adds a lot: <a href="http://hackedphpbb.blogspot.com/2009/01/place-holder.html" rel="nofollow">http://hackedphpbb.blogspot.com/2009/01/place-holder.html</a>