Let's say you've finished building the HTML and the server-side validation code for your registration form, and you're now ready to write the code which stores the user's information (probably in a database). How should you handle the password?

The most obvious approach is to store it as just another column in the user table, with no special consideration. Many novice developers do exactly this—after all, you need access to the database to view the contents of the user table, so the passwords are protected, right?

But what happens when an attacker gains access to your database—for example, by guessing or intercepting your phpMyAdmin password? They have instant access to all of your user's passwords without even trying.

(Perhaps your application is trivial, and your users' accounts don't provide access to anything sensitive—who cares if an attacker gets their passwords? Well, many people use the same password for all of their accounts—email, bank accounts, and so forth. Our hypothetical attacker might not be able to do much damage on your site—but if the email addresses and passwords he just obtained allow him to gain access to other, more sensitive accounts, then you have a problem.)

Encrypting the password before storing it in the database is the obvious solution to this problem. Simply run it through your favorite encryption algorithm, and save the encrypted version; when the user logs in, just decrypt it to check the entered password.

This is also the wrong solution to the problem. An attacker who has access to your database probably has access to your file system, as well—which means they can easily find your encryption code and any keys it may use. Your encryption is useless in this case.

(Whatever you do, don't write your own home-brew encryption function, or run the password through a series of different encryption algorithms and arbitrary transformations, thinking this will make it more secure. It won't. In fact, this approach may leave telltale mathematical traces in the ciphertext which will make it easier for a skilled attacker to compromise your system. Leave the design of encryption algorithms to the experts.)

A better method is to hash the password, rather than encrypting it. Hashing is a form of one-way encryption: converting a password to a hash is easy, but reconstituting the password from the hash is mathematically impossible. Think of a trap door, or running a steak through a meat grinder—once something has gone through a hash function, it can't go back.

(Since the original string can't be reconstituted, hashing technically isn't encryption, no matter what anyone may tell you. I merely described it as such for illustrative purposes.)

But if we aren't storing the password in a way that can be decrypted, how can we check it when the user tries to log in?

Simple: hash the password entered on the login form, and compare that to the hashed password stored in the database. If the two hashes are the same, we know that the user entered the correct password.

(Incidentally, this is why many systems can't tell you your password when you forget it—they don't know your password. They only know its hash value. These systems typically handle forgotten passwords by asking you to choose a new one. Any system which is capable of providing your password on demand must be using some kind of reversible encryption—or, God forbid, storing it in plaintext—and should be considered less secure.)

PHP's md5() function is the standard hash function used for this purpose, but I prefer the more cryptographically robust sha1().

This is a lot better than our original system, and it's good enough for many applications. But our system still has a weakness.

Again, assume that an attacker has access to our database (and therefore our password hashes). Though he can't convert the hashes back into passwords, he knows that most people choose plain English words, or minor combinations and permutations thereof, for their passwords.

It's easy to generate a table of English words and their corresponding hashes (known as a rainbow table). With this in hand, an attacker simply has to compare your password hashes to the rainbow table until he finds a match. There are even pregenerated rainbow tables online.

(This is why good systems encourage you—or even force you—to choose complex passwords which don't appear in dictionaries. Generating a hash table based on an English dictionary is easy; generating one for every possible password-length string of ASCII characters is effectively impossible.)

For kicks, I once ran about 15,000 real-world password hashes (from a system I administrated) against the above-linked rainbow table. I was able to crack about two-thirds of them. Clearly, this is a serious vulnerability for any system which needs high security.

Fortunately, there's a simple and elegant solution: salt your passwords before hashing them, by concatenating them with a randomly generated string.

For example, let's say the user has chosen "ravens" as their password. If we simply hash this, it will be vulnerable to even the most basic rainbow attack.

So, instead, we'll generate a random string, four to ten characters long. (This is arbitrary; a few characters is sufficient.) This is known as the salt. (For convenience, I like to restrict my salts to printable ASCII characters.) Let's say our random-salt-generating function returns this:

^p]K~7

We prepend the salt to the password, and get:

^p]K~7ravens

Finally, we hash that string, and store the hash and the salt in the database. To check login passwords, we simply repeat the process (retrieving the original salt from the database, rather than generating it anew), and compare the hashes as before.

We've effectively turned a vulnerable, low-strength password into a strong one. Yes, our attacker can see the salt, and he could generate a rainbow table based on English words prefixed with that salt. But since the salt is different for every user, he'd have to generate a separate rainbow table for every user. The costs in time and storage space are prohibitive.

All of this may seem complex at first, but you're really only dealing with two database fields (the hash and the salt) and a couple of functions: one to generate a random salt, and one which accepts a plaintext password and a salt and computes the hash. Here's some sample code.

function generate_salt() {
    $salt = '';
    for ( $i = 0; $i < rand( 4, 10 ); $i++ ) {
        $salt .= chr( rand( 33, 126 ) );
    }
    return $salt;
}
 
function hash_password( $password, $salt ) {
    return sha1( $salt . $password );
}
 
// for user registration, do something like this
$password = getPasswordFromRegistrationForm();
$users_pw_salt = generate_salt();
$users_pw_hash = hash_password( $password, $users_pw_salt );
// store $users_pw_salt and $users_pw_hash; forget $password
 
// and for user login, do this
$users_pw_salt = getUsersPasswordSaltFromDatabase();
$users_pw_hash = getUsersPasswordHashFromDatabase();
$entered_password = getPasswordFromLoginForm();
if ( hash_password( $entered_password, $users_pw_salt ) === $users_pw_hash ) {
    // the correct password was entered
} else {
    // the password was incorrect
}