Code Away

In a hurried attempt for “increased security”, portal developers are coming up with really wierd ways to ensure that users don’t keep simple passwords which can be broken with dictionary attack. For example, our very own State Bank of India, recommends (imposes) this:

• Password length should be greater than 8 and less than 20 characters
• Password should contain at least one digit [0-9], one alphabet [A-Z] [a-z] and one special character such as [@#&*!]
• Please avoid choosing a password that is generic in nature, guessable or inferable
• Avoid password from your personal data such name, date of birth, address, telephone number and car number
• It is good practice to commit your password to memory rather than to write it down somewhere

Perfect. My generally-used password is 7 characters. So now I have to think of another word, which should have all of the above restrictions, and in addition, shouldn’t be written down anywhere! (As if recovering that password is just a snap)

The problem with overly complicated passwords is this: There are simply too many good things in my life to remember, so in all probability, I am bound to forget this special-character-sprinkled alphanumeric password if I don’t use it within 10 days of its creation. As a result, I am going to be extra cautious and write it down somewhere, irrespective of what SBI recommends. And the moment I write it, my security is compromised.

As Jeff Atwood has rightly pointed out, having a pass phrase instead of a password increases the security in itself, without having to memorize garbled strings. This is because passphrases are far less likely to be broken with dictionary attacks.

We have to encourage users to stop thinking of passwords as single words, and start thinking of them as pass phrases. The worst imaginable pass phrase (eg, “this is my secret password”) is many times more secure than an average single word password (eg, “god123″). And it’s easier to remember.*

As a developer, you need to do your part, too:

1. Absolutely, positively make sure your applications support a password field length of at least 128 unicode characters.
2. In the user interface for defining the password, remind the user that password doesn’t literally mean a word. Give several examples of pass phrases directly alongside the entry field. It’s absolutely imperative that we educate the users– how else will they know there’s some other way to deal with that input box?

The greatest long term security threat isn’t hackers. It’s the perpetuation of the braindead 8-16 character password length limitation, and the idea that passwords are single words.

On a tangential note, if State Bank says “This is your account”, then I believe I’m supposed to understand that I own the account, and any problems in my account are a result of my clumsiness in protecting it (apart from a basic few things that the account provider should give, like encrypted password storage on server). So why am I not allowed to choose the password I’d prefer? I never heard of anyone selling a house with the clause that the buyer is supposed to use locks only from Company X.

Developers, please just concentrate on securing your server, and let the users decide how much security means for them. I might want to sign up for a jukebox website with the password “12″. So what? It’s just a jukebox, not some e-nuke. You want to encourage your users for better passwords? Have hints alongside password boxes, and provide password strength meters. Email them (say twice in a year) suggesting (and not imposing) password change if necessary. That’s good enough.

Give your users the freedom to decide for themselves.

Update: The perfect comic for this post