Would this be considered absurd for password hashing? [closed]

It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center. Closed 11 years ago.

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 = "Pickl开发者_高级运维es";
$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?

---

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).

---

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"?

---

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.

---

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.