Web Developers: Don’t Be Password Idiots
June 22nd, 2009 | By Ian in Development, Opinion, Rants, Security, Sites of Interest | 7 Comments »As 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.
They say clothes make the man, so it stands to reason that the theme makes the blog. After receiving several moans about my blog’s styling, I’ve finally decided to do something about it. No more Kubrik theme for me. 
Many websites offer the flexibility to display the same page via both SSL and HTTP. The major problem with offering this is the possibility that embedded content will not be served via the same protocol; many browsers will throw an error if an SSL page embeds HTTP images.