Password Security From A Developer’s Perspective

One of my biggest pet peeves has to do with password security – and why some websites still don’t take password security seriously. In this article I will go over some of the common limitations and bad decisions I’ve seen, and why there is no reason for any website to have them in place:

No Special Characters

Virtually all security experts agree the best way to make a secure password is by using a mixture of alphanumeric characters (A-Z and 0-1) in addition to special characters ( !@%$)&^ ). So why is it so many websites still disallow special characters? It is simply mind boggling.

For starters, if you are properly developing your application, special characters should not matter for data that is going through a hash algorithm (you do hash your passwords, right?) The algorithms only care about bits and bytes – as far as they are concerned an A is no different than a % other than the bit values they represent.

Length Limits

One of the financial sites I use on a regular basis limits passwords to 10 characters. While yes, a 10 character password is a lot better than 90% of the passwords used on a daily basis by most people, it is still insecure. But that is an argument for another day.

My point is, why have such a low limit? I do agree a limit is needed (after all, you don’t need people sending a megabyte of data every time they log in), but the limit can be fairly high. Theoretically a hashed password will always be the same size in the database – whether the original text was “abc” or “123456789012345678901234567890″ – it doesn’t matter. So please, stop it with the annoyingly low limits.

Not Hashing The Passwords

This is just plain stupid. There is no reason in the entire universe to ever store plain-text passwords in your database.

– Once Again –

There is no reason in the entire universe to ever store plain-text passwords in your database.

Get it? It sickens me how many services out there still literally email your password, in plain text, when you use their “forgot my password” function. Just stop it. Please hash the password and if they forget it, have a verification test set up, and if they pass it let them make a new password.

Otherwise you’re just asking for a script-kiddie to cause trouble.

Oh, and do use password salts.

Change Password Fields

One of the best security measures you can put in place is requiring the user to enter their password to change their login name (email/username/whatever) or to change their password. The reason being – what if someone intercepts a cookie?

Without requiring a password they can steal the account very easily. By requiring a password it makes it much more difficult. And that leads me onto my next point…

Cookies

And last but not least is cookies. No – not the edible delicious treats – but those little bits of text that let you store session data.

A login cookie should never have your password (even hashed) in it. When a user logs in an id should be generated – unique to this session – which will be used to identify the user. That id will then be stored in the database and in the cookie and will only be valid for as long as the cookie is valid. Heck, you can even do a mixture of a user id and the session id.

Either way if the cookie gets intercepted a malicious user will still be able to get in – but at least this way their password is safe.