Web Developers: Don’t Be Password Idiots
22 June 2009 | By Ian in Development, Opinion, Rants, Security, Sites of InterestAs a follow-up to my last post, here are a few tips to help keep you from driving your site users away with misguided password restrictions.
#1: Consider Context
Your tweets may be precious to you, but as a web developer, you should understand the differences between password security for Twitter and for online banking. Consider the monetary and legal damages that to both you and your customers if their account were compromised and plan accordingly.
#2: Character Taboos
Since you are properly protecting passwords by only storing a hash, there is no reason to limit characters they use in their passwords. Don’t tell your users they can’t use symbols or start their password with a space if that’s what they want to do. In the end, all you’ll be storing is an alphanumeric hash of the password anyway, so it shouldn’t matter if they send you a bunch of binary gook.
#3: Password Rotation
Set reasonable requirements for password rotation. If yours is a high-security system, it is reasonable to require password rotation every few months. In order to prevent abuse, it is even reasonable to check for duplicates against the last N password hashes or all of the hashes used the last few months. Before implementing any password rotation scheme, be sure you’ve visited and revisited #1 above.
Despite the practices of some sites, there is rarely if ever a good reason to keep an unlimited log of every password a person has used, never letting them be reused.
#4: Minimum password lengths
Let’s assume someone really wants into one of your user’s accounts. If they had the capabilities of attempting a blistering 1,000 different passwords per second, here’s how long it would take to try every possible combination:
| Min length | a-z | a-z, A-Z | a-z, A-Z, 0-9 | a-z, A-Z, 0-9, Symbols |
|---|---|---|---|---|
| 6 | 3 days | 225 days | 2 years | 22 years |
| 7 | 90 days | 32 years | 110 years | 2,035 years |
| 8 | 6 years | 1,663 years | 6,814 years | 191,258 years |
| 9 | 166 years | 86 millennia | 422 millennia | 17,978 millennia |
The exponential growth of possible combinations makes password cracking infeasible pretty quickly. Assuming 1,000 attempts per second is ludicrous against a webserver, but assuming your database isn’t compromised, this should be the only means an attacker can brute force an account. The time to compute reaches absolute absurdity after just 8 lowercase characters.
#5: Maximum Password Lengths
As in character taboos, what do you care if your users have 100 character long passwords? It is reasonable to put a ceiling on password lengths to prevent blatant abuse (perhaps in the neighborhood of 500-1,000 chars), but don’t limit your users to a 12 character password because that’s all your schema can hold.
Remember that you should be hashing passwords and that most hashes produce a fixed-length output no matter the input.
22 June 2009 | The Dave Said:
#6: Salt your hashes. For the love of jeebus, use salt. I don’t care what your blood pressure is, throw some salt on your hashes right here and right now.
23 June 2009 | Arjan’s World » LINKBLOG for June 23, 2009 Said:
[...] Web Developers: Don’t Be Password Idiots – Ian Some important tips for implementing a password scheme on your website [...]
25 June 2009 | Stefan F Said:
Nice article, but here is another idea: Even 4 characters may provides sufficient security if used with a max amount of wrong attempts – throttling down the number of brute force attempts from 1,000 per second to 5 per day makes a considerable difference in you table ;)
25 June 2009 | BlueBoden Said:
I just had to deal with the same idiocy on paypals development site. They forced me to use at lease one upper letter character in my password, even though i had underscores included.
That was where it hit me, that I’d much rather have them generate my password as a user, then spend time making a new one for their site alone, not to mention writing it down afterwards.
It would be cool as a second option, if you must have these ridiculous “security” features.
The most annoying “security” feature, is the secret question. I almost always just hit in a bunch of random characters on those. REALLY, secret question should be optional, not required!!
But its no worse then pointless CAPTCHA’s, like the one found on this blog, design your own CAPTCHA system damn it, and only throw them out when a visitors behaviour reassembles that of a bot.
The “stop spam. read books.” CAPTCHA is paticuler useless, and should be avoided at all costs. In that it fails about 70% of the time, and annoys users. And in that its effectively digitalizing books, and not giving people anything in return for their efforts.
25 June 2009 | kevin Said:
Key thing about the type of characters input into a form is for server protection. Sure, you might be storing it as a hash or something, but I think the aim is to avoid people inputing binary/shell active code into a form.
25 June 2009 | kevin Said:
Also, OpenID is the solution to this stuff. We all should be using it.
08 January 2010 | Krumpet Said:
Agreed. I use some sites that have the most ridiculous password rules (Merrill Lynch, Smith Barney, I’m looking at BOTH of you). It’s like their devs never bothered to think at all. Frustrating.