Would this be considered absurd for password hashing?

Question

This is sample PHP code I made to hash a string. Does this method have any extra security benefits or is it not practical at all?

<?php
$string = "Pickles";
$salt_1 = "8w87wv87w43j78wv43jf4wv34zv3wv43twvv";
$salt_2 = "mnd9r4ng8rnf903ng8gm6ks9rhr74ner7fu4";
$salt_3 = "4hr84h4yeu3je8u3ir94j59ti5i59it5j5i9";
$layer_1 = sha1(md5(hash($salt_1.$string.$salt_3)));
$layer_2 = sha1(md5(hash($salt_2.$layer_1.$salt_1)));
$layer_3 = sha1(md5(hash($salt_3.$layer_2.$salt_2)));
$final_result = $layer_3;
echo $final_result;
?>

Any thoughts or suggestions?

Password Encryption != Password Hashing. – Kendall Hopkins Oct 08 '11 at 03:38 — Kendall Hopkins, Oct 08 '11 at 03:38
It's not that secure, the password is 'Pickles' – Andrew T Finnell Oct 08 '11 at 03:41 — Andrew T Finnell, Oct 08 '11 at 03:41

score 2 · Answer 1 · edited May 23 '17 at 11:46

No, it is not overkill, it is heavy collateral damage.

You have several "salts". Having many salts is useless, but harmless. However, your "salts" seem to be constants -- and that's much harmful. A salt must be unique for each hashed password; otherwise, it is not a salt and it does not the job of a salt, which is to prevent an attacker from attacking several passwords in parallel ("parallelism" is to be taken both timewise and spacewise; a big table of precomputed hashes is timewise parallelism).

Moreover, you invoke 6 hash functions (or maybe 9, depending on what your hash() function is supposed to mean). That's way too few. 100000 invocations would be closer to an appropriate count. The multiple invocations are meant to make the password processing slow -- slow for the attacker who "tries" passwords, that is (unfortunately, this makes it slow for your server too, so you cannot bump up the iteration count at will).

See this answer for details. And then this one. And use bcrypt (there is a free opensource implementation of bcrypt in PHP there).

score 1 · Accepted Answer · edited May 23 '17 at 11:53

MD5 and SHA1 are one way hashes. Is it your intention to decrypt these messages in order to read them later? If not, this is not encryption. It is merely obtaining hash values of a string that has been encrypted with a salt key, three times. Here's some sound advice on inventing your own encryption algorithm:

http://diovo.com/2009/02/wrote-your-own-encryption-algorithm-duh/

https://security.stackexchange.com/questions/2202/lessons-learned-and-misconceptions-regarding-encryption-and-cryptology

Is this kind of encryption "safe"?

score 1 · Answer 3 · answered Oct 08 '11 at 03:54

I can't tell you if your approach is appropriate or not, because I'm not a mathematician.

However, I can say that you don't truly understand how password hashing works in practice.

Repeatedly hashing a string does not necessarily make it any more "secure". Do it right according to best practices (using crypt() and BLOWFISH) and you will be ok. Go off on your own "best" path and you're likely to get burned... somehow.

There's a reason for relying on best practice. Unless genius is involved (no, real genius), "improving" on it won't be beneficial, and you must understand it anyways to truly improve on it.

score 0 · Answer 4 · answered Oct 08 '11 at 03:43

0

Each time you hash you actually increase the likelihood of collisions and use increased CPU resources without actually increasing security. Just salt it, sha1 it and call it a day.

answered Oct 08 '11 at 03:43

Matt Williamson

39,165
10
64
72

Would this be considered absurd for password hashing?

4 Answers4