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

Never store the password in a reversible way, always use One-Way-Hashes. Checking works by encrypting the entered password and checking the two hashes against each other.

Answer 2

"Correct?"

If you need a binary answer:

 1

Answer 3

You should store a hash of your password instead of the actual readable string, also consider using "Salting" for extra security

Answer 4

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 5

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.

Answer 6

There are many variations on this theme.

For good information, please read this: http://en.wikipedia.org/wiki/Digest_access_authentication.

Then read this: http://tools.ietf.org/html/rfc2617

Generally: You only store a digest. Never a password.

Following RFC2617, you should store a digest of username, realm and password.

The client ("agent") takes username, password, realm, etc., and creates a digest, which it sends to your server.

Your server, based on username, looks up it's version of the digest.

If their digest == the digest saved in the server, you agree on the password (and everything else).

If their digest != the digest saved in the server, you disagree on the password (or something else). Which means they didn't get the realm or username right, or they didn't get the nonce right, or something else went wrong. They can't be trusted.

The full RFC2617 includes other data to compute a digest of other stuff and the password digest just to be absolutely sure that the client is doing the responding.

Answer 7

The reason you store a hashed password is that if someone manages to get hold of the data in your user table, they still can't log in. A one-way-hash can't be decrypted (not even by the person who encrypted it!) so it is very difficult to use the hashed password for anything.

Because you can't possibly decrypt the password in the database, you need to take the password that has been entered and repeat the same process to hash it and then compare the hashed values to find a match. Because of this, your salt can't really be totally random as you will end up getting different results.

On top of this, you don't really want a password to be transmitted in its unencrypted form, which is why login-pages are normally HTTPS pages.

Answer 8

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.

"One way" in cryptography means "hard to invert." Simply put, it means that if I give you sha1(password), you cannot find password in any reasonable amount of time.

This is called computationally one-way. Many people confuse this for another definition of one-way (from mathematics) meaning "not one-to-one", which does not apply here.

Answer 9

I strongly advise against the use of MD5. For further information, read the Wikipedia section [MD5] Security. I recommend to use the SHA-1 hashing algorithm instead.

Answer 10

Avoid using MD5 hashes if you can, as it's pretty flawed.

Alternatives are SHA1, or even better SHA256 or SHA512.

Answer 11

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

Salts should be random. Their sole use is to make brute-force attacks on hashes much more expensive. Something called a "rainbow table" (which is a fancy name for a database where someone hashed a whole bunch of possible passwords in advance, and lets you look up passwords if you know the hash) makes it possible to take unsalted password hashes and turn them into passwords in a fraction of a second in many cases.

A moderately sized salt can increase the complexity of a precomputed brute-force attack exponentially. For every single bit of random data in your salt, you double the time required for a precomputed brute force attack. For every unique salt value in your database, the attacker has to start over when attacking the password protected by that salt.

If you had 1kB of random salt for every user's password, precomputed hashes would be out the window. You wouldn't affect the amount of time it would take to brute-force a single user's password though.

One way you can make the brute-force attacker's life harder is by making the hashing process computationally intensive (e.g. 5000 rounds of sha1(salt+sha1(salt+sha1(salt+password)))). You only have to do that for every login attempt. The attacker has to do it for every salt + password combination they want to guess. You have to decide if this is something that is worthwhile for your needs. The answer is probably no.

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

I'm paranoid, but I would say any information that you the site owner doesn't need while the user isn't logged in should be encrypted with a derivative of the user's password. That way attackers don't have access because you don't have access.

For an online order processing system, for example, you might need their mailing address, their name and most recent order unencrypted, but their order history and favorite color might be encrypted with their account password.

Note that if you do this, and they lose their password, the protected information is lost also.

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.

A hash is a method for systematically throwing away information. Say you start with a string, and produce "srflcdos" by throwing away all but about every fourth character. The text I "hashed" could be: "spear if fish lies calmly. don't sit!", or it could be: "supercalifragilisticexpialidotious". There is no way to prove either way.

Cryptographic hashes do a lot more mixing and other transformations along with the throwing away, to make them more secure for small amounts of input data, and to avoid leaking any facts at all about the input data. As an example of an insecure hash, if you know that whenever the input contains the letter A, the 12 bit of the hash is 1, then you are exposing information about the original text, and the result is not a cryptographically secure hash.

The principle is that you can't reverse engineer a process if between each transformation you throw away information vital to reversing the previous transformation. An MD5sum produces 128 bits of output, regardless of whether you put in 1 bit or 12 petabytes of information. You obviously can't compress 12 petabytes into 128 bits, so information is clearly being thrown away in the process of computing the hash.