I’d like to think that I deal with passwords the way most developers do. When dealing with registration or something else that requires the user to provide a password, I follow some general guidelines:
- The password must be a minimum length, normally no less than 6 characters
- The password’s maximum length is very high (200 characters)
- I’ll typically check for at least a mix of letters and numbers. For applications with considerably more sensitive data, I’ll have more requirements – such as mixed casing or special characters.
- Hash the password with a salt (the salt can be a fixed string, or something more unique to the user – again based on sensitivity). Salting means that if someone gets access to a dump of your Users table, they’ll still have a hard time logging into the system with a dictionary attack.
- Since hashes can’t easily be reversed, send out a new password to users when they forgot password and have them change the temporary password as soon as they log in.
All this is pretty vanilla and you can change an SHA1 hash implementation for some encryption or whatever else tickles your fancy. What I’ve noticed though isn’t that developers are hitting some type of technical hurdle when dealing with password, but rather, a usability one. The point behind bullets 1, 2 and 3 is that users ought to be able to enter anything they want as a password, provided it meets a minimum set of guidelines. As developers, we should try very hard never to impose restrictions which limit the effectiveness of a password. Lately though, I’ve been astonished at some of the limits sites impose on passwords – forcing me to come up with a less secure password than what I would have liked.
Here are some popular sites which have such restrictions:
- digg only accepts letters and numbers
- SourceForge only accepts letters and numbers (when you change your password, SourceForge even goes through the trouble of showing you a little dynamic update as you type (weak > normal > strong and then “invalid character” when you enter an exclamation mark)
- Passport limits password to 16 characters (isn’t Microsoft a champion of passphrases?)
- MySpace only accepts passwords up to 10 characters long, but at least require 1 number or punctuation character
- Wikipedia let me register with a password of ‘a’, but at least has very informative help on choosing a strong password. (Additionally, given what an anonymous user can do on Wikipedia, I’m not too disappointed in this policy)
And for sites with better policies:
- Ebay, PayPal and Google have useful help and accept special characters (PayPal and Google even require at least 8 characters),
- Twitter and Facebook don’t have any “choosing a strong password” help, but still seem to accept everything
The most shameful site I’ve ever come across though is completely unacceptable – not only because of the ridiculous limitations it puts on passwords, but also the type of data it’s responsible for. The Bank of Montreal’s Mosaik Credit Card (BMO is major Canadian bank), has a password limit of 8 characters and only accepts letters and numbers (there’s actually a maxlength=”8″ attribute on the form).
Here’s a simple rule to follow. If Windows Calculator displays the total number of possible combinations in non-exponential form, you password guidelines suck.