.png)
One thing that struck me when I was developing Quocial last summer was that I was spending a staggering amount of time on details that had little to do with the core functionality of my site. Thousands of little things go into making a webapp that works the way people expect. And yet, even when using a convention-over-configuration framework like Rails, developers constantly stumble into common problems and spend hours reinventing common solutions.
So, I’ve decided to start cataloging these frequent sticking points. Eventually, I’d like to organize them into a book, tentatively titled The Web Application Checklist. But for now, I’m just going to post them here on an as-I-think-of-them basis, with the tag wach. These entries are rough drafts and subject to heavy revision.
Today’s item: passwords. If your application has enough of a need for security to require a password, it should require a good password. So when a user tries to create an account secured by the string 123456, just don’t let them. If their password is in the first 10,000 guesses that Password Recovery Toolkit might try, tell them to pick another. Then implement some kind of throttling and/or CAPTCHA. If you fail to do this, accounts will be hijacked. This goes double for admins: As Twitter learned, you can’t even trust your own colleagues to pick good passwords.
Each time someone picks a password, run it by the Top 500 Worst Password of All Time. Reject it if it differs from anything in the list only by one or two characters. There ought to be a good, standard, open-source library for doing this, but I’m not aware of any (suggestions?), so you might have to hack together some regex yourself.
And, for those of you who’ve never done this before, don’t forget to only store the hash in the database, and salt the hash. Here’s why.
[Update, 1/21: Here is a nice overview of security concerns for webapps, including passwords. And here is some JavaScript code used by Twitter after The Incident to reject common passwords.]
Tags: wach