Hash Functions and Keeping Passwords Protected

Question

I have been wondering a lot about different forms of Hashing and such for passwords. Yes I know about salting and would probably add that to the hash, but this is without any salting. I would probably use a dynamic salting technique.

Aside from all of that I was wondering if it was even logical to do what I show below?

<?php

$data = "David";
$hash_crc32 = crc32($data);
$hash_md5 = md5($data);
$hash_sha1 = sha1($data);
echo '<br /><br />' .$hash_crc32. '<br /><br />' .$hash_md5. '<br /><br />' .$hash_sha1;

?>

The Echo Outputs the following:

1180170431

464e07afc9e46359fb480839150595c5

d27937f914ebe99ee315f04449678eccfb658191

$hash_crc32_md5 = $hash_md5 + $hash_crc32 + $hash_sha1 . $hash_md5 . $hash_crc32 . $hash_sha1;

<?php echo '<br /><br />' .$hash_crc32_md5; ?>

That Echo Outputs:

5820170431464e07afc9e46359fb480839150595c51180170431d27937f914ebe99ee315f04449678eccfb658191

So do you think it would be an over kill to hash a password like this? Should I just stick to one form of hashing with salting? I know I cannot be the first to think of something like this as it just seems really obvious.

As well how much harder do you think it would be to run across hashing collision, etc. with this form?

Thanks for any responses! :)

Answer 1

Is it overkill? I can't comment as to that. I will state that it's probably less secure than using only one of the methods (in terms of information theory).

The reason is that you're actually supplying more information to a prospective hacker by giving the results of multiple hashing algorithms.

There's nothing at all secretive about the algorithms used in these hashing methods. Hashing removes information by virtue of the fact that, while it's reversible, there are are large number of possible texts that could produce the same hash.

However, in providing multiple hash outputs, you effectively remove a lot of those possibilities since, for example, the number of texts that can produce a particular MD5 is intersected with those that produce a particular SHAx.

Think in terms of the MD5 hash you have. Maybe there are a trillion different texts that can produce that value. That's an awfully large search space.

Now consider the SHAx hash. There may also be a trillion different texts that can produce it. Again a large search space.

But, if the intersect of those two search spaces is forty-two different texts, that wouldn't take long to crack.

Cryptography is not for the faint of heart, or for those that haven't got a doctorate in the field :-)

Answer 2

The point of a hashed password is that you are still able to verify a password against it by hashing a plaintext password the same way you hashed it the first time, then comparing it against the stored hash, without being able to reverse the hashed value into its plaintext form. In that sense what you're doing doesn't take anything away from that purpose.

The weakness of hashing is largely twofold: it may be possible to brute-force a hash if it is relatively inexpensive to go through all possible passwords, hash them and compare them to the stored hash. In that sense, your technique adds a tiny bit of security since your triple hash thingy takes a bit longer to compute than just one plain hash, so an attacker needs more time to try all combinations. It's not really significant though. A better way of achieving that is to use a slower hash algorithm and/or simply repeat the hash operation a certain number of times (100-1000+ times).

The other weakness is rainbow tables, where somebody already went through the trouble of creating a table that maps all possible passwords to their hashed value. Your technique adds a little bit security here in that your particular algorithm is unlikely to have an existing rainbow table somewhere. It does not help where two users have the same password, because those will both hash to the same hash, so an attackers gets two for one. This is where unique salts per user are important, because it means an attacker needs to try every password for every user individually, instead of every password only once for all users.

So, what you're doing does not really add anything that hasn't already been done better, and most critically still lacks a unique salt.