Am I supposed to store hashes for passwords?

Question

User System and Passwords: I was looking through MD5 stuff, and I am wondering what is the normal/good practice for passwords. Right now, I think people super encrypt the passwords and store the hashes. If so, how does password checking work? I just have the input password go through the encryption process again and then check the hash with the stored one, correct?

This question may contradict the above, but should my salt ever be a randomly generated value? If so, when may it be useful?

Edit: Other than passwords, in a user system, what else should be encrypted as a good practice? Do they encrypt usernames or anything else?

2nd Edit: What is a one-way hash? I mean, technically, can I not reverse engineer my source code? Maybe this is a bad question because I do not know much about one-way hashing.

Answer 1

First you create a salt.

Note examples are written in PHP

// Setup a salt, this isn't "random" but it doesn't really have to be
$salt = sha1(microtime());

Then salt the password

// First we hash the password, then XOR it with the salt hashing the result
$hash = sha1(sha1($password) ^ $salt);

Store the $hash and $salt in the database.

When the user enters a password compare it to the hash

if(sha1(sha1($entered_password) ^ $salt) == $hash)
    // Correct password

Never store passwords in a reversible format. Also I would advise against using MD5 as a hash.

Edit: Other than passwords, in a user system, what else should be encrypted as a good practice? Do they encrypt usernames or anything else?

Passwords aren't encrypted, they are hashed. Picture a hash (very simplistic) as something that takes a number and multiplies it by ten. Say I want to hash the number 30. I would say 30*10 and get 300 as my "hash" for 30. Note that you cannot derive 30 from 300 without knowing how the hash function works.

That's a very simplistic "hash" and if you know it always multiplies by ten then you could easily reverse it. Now take a look at the SHA1 hash function. It's much more complicated. It can't simply be reversed.

You will find that rarely is anything except the password hashed, and nothing is encrypted. The amount of overhead you would have with encrypting your database would be enormous.

I suppose you could apply a similar salt / hash pattern to the username, but then you have pitfalls. What if you want to use that username somewhere in your code? What if you want to check to make sure it's unique to the table?

2nd Edit: What is a one-way hash? I mean, technically, can I not reverse engineer my source code? Maybe this is a bad question because I do not know much about one-way hashing.

See above (or click here). A one way hash is just that. One way mapping. A => B and nothing else. B !=> A, and A can't be anything except B.

Someone mentioned the performance of an XOR operation. While I feel performance is largely negligible I ran a quick test.

function microtime_float()
{
    list($usec, $sec) = explode(" ", microtime());
    return ((float)$usec + (float)$sec);
}

Now run

$start_time = $this->microtime_float();

for($i = 0; $i < 100000; $i++)
{
 $sha = sha1(sha1(microtime()) . sha1(microtime()));
}

$end_time = $this->microtime_float();

echo "1000 in " . ($end_time-$start_time) . " for CAT\n";


$start_time = $this->microtime_float();

for($i = 0; $i < 100000; $i++)
{
 $sha = sha1(sha1(microtime()) ^ sha1(microtime()));
}

$end_time = $this->microtime_float();

echo "1000 in " . ($end_time-$start_time) . " for XOR\n";

Repeat as much as you want. The initial writeup uses the error log and I got the following results:

1000 in 0.468002796173 XOR
1000 in 0.465842008591 XOR
1000 in 0.466115951538 XOR
1000 in 0.498080968857 CAT
1000 in 0.506876945496 CAT
1000 in 0.500174045563 CAT

Answer 2

Standard practice with passwords is to not store the original password anywhere. Unix passwords used to be encrypted with "crypt" that would use a random salt. The salt itself was stored in the first two characters of the encrypted password. When the user entered his password, the system would use the two characters of the encrypted password as a salt to encrypt the entered password, and if the encrypted result was the same as the stored encrypted password, it was a match. Similar things can be done with MD5 passwords.

That's why good sites will never email you your password, but instead will reset your password to a one-time only value - because they don't know your password.

To expand on this a little bit: an MD5 hash is a one-way function - if you hash the same value you get the same hash, but you can't take the hash and somehow turn it into the value. There is a small but finite chance that two values will produce the same hash (the chance gets higher the larger the initial strings are or the smaller the hash is), but they choose the hash algorithms to make the chances that two strings people would choose as passwords would hash to the same value almost infinitesimal. You can think of a one way hash as being like a meat grinder - you can look at the meat that comes out of your meat grinder and see if it's cow, lamb or pig, but you can't pass it through the other way and get back a cow.

Because of this, nobody can recover your password because it's never stored anywhere on their system, only a hash of it.