There are several techniques used for storing passwords; some are very good, while some are downright terrible.  Without mentioning the name of the organizations (for security purposes), I am, and have been associated with 2 groups that, without a doubt in my mind, store passwords in an extremely insecure manner.  And of course, they’re not alone.

It is easy to spot an organization that stores passwords either completely unencrypted or encrypted using a method that allows for decryption easily.  One method to spot this insecure behavior is the ability to “recover your password” without the need of resetting it.  If you can recover your password, then someone else can easily access it as well (with the right tools).  Another method is one to spot carefully… it’s not to fear when a company requires your password to be different from your previous X passwords, but when they also look for similarities and judge your password to be “too close”.  This may come off as being a very secure tactic, when indeed it must mean that they are storing not just one, but several old passwords in a way that would make them, once again, an easy target.

So now we know some things to spot visibly that should throw up some caution flags.  What else is there to know.  There are methods of storing passwords that are more secure.  For instance, storing a “hash” or checksum of a password using an irreversible, or one-way, algorithm is a good start.  There are several hashing methods out there, some of which are better than others, but before we continue, allow me to explain what a hash is and how it can benefit secure data storage.

Sparing you from all the techno-jargon, a “hash” or checksum is an “encrypted” form of a variable.  That’s a few quotes thrown in there, technically the term hash is misused by the Internet community as is encrypted when talking about a checksum.  Encrypted would technically make the statement that the process is reversible using some sort of key.  When in all actuality there is no key, it is a one-way cypher resulting in a fixed length string of letters and numbers that is unique to the variable data.  A common hash string (MD5) is 128-bit or 32 hexadecimal characters.  In short you have 32 characters ranging from 0-9 and A-F, 16 possible choices for each character position, giving you approximately 340,000,000,000,000,000,000,000,000,000,000,000,000 possibilities.  This doesn’t eliminate the possibility of duplicate checksums, but obviously the chances of that occurrence are highly unlikely.  The benefit of storing a data in “hash” form is that if a person gets a hold of a list of passwords, they are much easier to enter than if they get a hold of just your password hashes, but there is still a weakness.

Passwords are only as good as the people that make them.  Of course a developer can submit their users to a multitude of password rules, eliminating common passwords and other occurrences, but you’re still left with the possibility of 2 people having the same password.  If 2 people have the same password, they therefor have the same hash.  So how do we eliminate this?  Now it’s getting fun!

Eliminating possible duplicate hashes in your database is the fun part, and the part that can really help you push forward into the realm of password security.  Salting your passwords is the easiest method to eliminate this rare phenomenon. A salt is small bit of data added “somewhere” to your password string.  As I said, this is where it can be a lot of fun if you’re creative.  The salt has to be stored, and should be unique to each individual user, otherwise you still have the possibility of identical hashes with the same password.  Attaching information collected during the registration process is a good start, or even using the “id” of the user.  Or you can be creative and use multiple items or even multiple times of running it through a hashing function.  This ultimately will be up to you, but I will give you a little guidance.

For convenience we will keep this easy.  The salt variable will be left undetermined in this sample so that you can fill it in with whatever you like.  Feel free to play around with it.

<?php
$salt=X;  //undetermined, replace X with something of your choosing.
$password=$_REQUEST['password'];  //Sent from a form, or other type of post/get data set.
$seasoned_password=$salt.$password; //This will joint the 2 together;
$password_hash=md5($seasoned_password);  //This can now be stored in the database along with the salt.
?>

Storing a salted hashed password will effectively eliminate the chances for duplicate password hashes, as long as the salt is wide enough variable.  Remember never to store your salt as it’s own field, hide it as something else.

I am indeed sorry if this was a little long and drawn out.  Security is not something to be taken lightly, and I hope this helps give insight in to how you can help protect your users passwords as well as the data you wish to protect.