Salting Passwords - How Do You Store Them?

[James]

So what's your idea of an expensive hashing function?

 

[Erik]

So what's your idea of an expensive hashing function?

I ran some tests in PHP, and this is what I came up with:

Hashing functions run over 10,000 iterations. Time in seconds.
MD5: 0.011883
SHA-1: 0.015976
whirlpool: 0.0442982
SHA-256: 0.02301
SHA-512: 0.0601192

SHA-512 is pretty good. You can also write your own expensive hashing function by doing something like this:

function my_hash($data) {
	$iterations = 10000;
	$algo = 'sha512';
	$previous = $data;
	for($i = 0; $i < $iterations; $i++) {
		$previous = hash($algo, $previous);
	}
	return $previous;
}

Every time it goes through the loop it uses the previous hash as the data. It's essentially like doing
sha512(sha512(sha512(sha512(sha512(... 10,000 times.

 

[James]

So, basically, the longer hashing methods you use, the more secure your hash is?
I think I might split a SHA1 hash and split a SHA512 into each character then hash them together as my hashing function in the future then.

$hash = 'SomeString';
$sha1 = hash('sha1', $hash);
$sha512 = hash('sha512', $hash);
$sha1[0] = substr($sha1, 0, 1);
// continue 'til end
$sha512[0] = substr($sha512, 0, 1);
// continue 'til end

$finalHash = sha1($sha1[0] . $sha512[0]);
$finalHash .= (sha1($sha1[1] . $sha512[1]);
// etc

$result = sha1($finalHash); // sha1 all of the previous sha1 hashes appended to $finalHash

 

[Erik]

So, basically, the longer hashing methods you use, the more secure your hash is?

Correct. The goal is to make it take painfully long to generate a rainbow table for a password or passwords, in case someone does happen to obtain the hashes and salt(s).

 

[James]

Thanks Erik I must remember to use painfully long hashing methods.

 

[Enigma]

Remember that the faster we can hash a password and compare it, the faster our login process works.

The difference between 5ms and 500ms would not be very noticeable to the end user, but it would make cracking a password take 100 times longer. So if it was going to take a week to brute force it, it would now take about 2 years.

So what's your idea of an expensive hashing function?

Bcrypt. Or you can use key strengthening as illustrated by putting a fast hashing function in a loop.

 

[Sim]

Besides, this app is not very important

Sorry to bring up an old thread - but I recently had it explained to me quite clearly why this attitude (which I myself had until recently) of "this app is not very important" is wrong on many levels.

The problem isn't that someone might be able to gain access to our forum - most of us really don't lose sleep over that. The problem is that, for the most part, people are lazy. They use the same usernames, email addresses and/or passwords on multiple systems, including some which are actually quite important.

Now we know that there is quite a lot of work involved to be able to first gain access to a database of users and their passwords, and second to be able to actually reconstruct the original passwords from what is stored in the database - but if you can do so, you can then apply what you've found easily to any number of vastly more important systems which might yield some very valuable results and return on the investment of trying to obtain those passwords in the first place.

You might not care about it if your users are silly enough to use the same passwords across all their accounts - but I think it is our responsibility as webmasters and website operators to prevent being the source of such attack vectors.

If you don't think it can happen - there's a very high profile and recent example: Gawker Media Hack: Everything You Need To Know - PCWorld

 

[Jason]

I disagree.

The point of the salt is so that one rainbow table cannot break every password in the database. The point of rainbow tables is that they're created in advanced and widely distributed to save on calculation. So, storing the salt separately if they're on a per user basis is rather pointless. It takes just as long to generate the table on the fly as it would to crack the password+salt combo directly.

Account security is the responsibility of the user. Regardless of how much effort and time is spent in making an application secure (and I agree, security is important, and site operators should ensure they're stuff is reasonably secure), the end user will always remain the weakest link. The threat you're protecting against by storing the salt separately is a person who can somehow access the salt in the database through exploitative means, but not the hash (in the database). It's highly likely that this person would have started computing a rainbow table in advance. assuming that he'll just be able to find the hash later. Not entirely impossible, but it's also not worth the engineering effort to defend against this one attack vector.

In other words, if you're going to store the salts in a "more secure" storage location, then it would make more sense to just store the hashes there as well.