Why Can't You Hash a Password Multiple Times

[Tjcrazy]

I've had this thought for a while - but always figured there was a reasonable solution to it.

 

I run a CMS system that currently hashes its passwords into MD5 and then into SHA1 passwords - or SHA256, depending on the system.

I've always thought why can't you hash passwords a lot, to make them more secure.

 

For example:

<?php
$password = 'ilovepassword1';
$securepass = sha1(md5(md5(sha1(md5(sha1($password))))));

echo $securepass;
?>

Apart from it being totally stupid, and inefficient - why isn't this a 'proper' solution?

 

Surely to crack it, you'd have to crack every layer- in the example above, 6 layers?

 

 

Would love an answer!

 

 

Tim

[sir West]

what about: sha512(sha256(sha256(sha256(<password>) + <username>) + sha256(<password>) + <password-set-date&time>)) ?

Adding user-specific and different types salting would surely make it harder, no?

[The_Decryptor Veteran]

Not really, you're not adding any actual extra work for the attacker, they still just have to come up with one password to test.

Edit: The hard part isn't "How many times do I run SHA", it's "What do I feed the hash function?", adding 3 hash iterations isn't any harder than just 1 hash iteration, it's just ever so slightly slower.

[Crimson Rain]

If you are hashing multiple times, it should be with different salts each time.

[Joe User]

I can't imagine that being very secure, if somebody attacks your database (Which is pretty much going to be the attack vector) they've then got your custom method for authenticating users.

If the method was properly secure, you could tell the attacker exactly how you're doing it and they still wouldn't be able to break it (Just because the attacker knows you're using bcrypt, doesn't make bcrypt any less secure, etc.)

 

First off, the production database server doesn't see the Internet. It doesn't even have a default gateway. It's locked down to VPN and local server access only.

Second, The stored procedure is compiled with encryption, it's not easily editable, and they would have to break the database security system to figure out how to decrypt it.

Third, I'm using bcrypt, but it's not on the forward facing server, it's out of sight in a stored procedure with much tighter security.

 

So, after breaking the VPN, breaking domain security, and breaking SQL Server security, they've figured out I'm using bcrypt. 

 

Now, if we coded security at the web tier, someone could break into the public facing server and figure out what we're using in far less time. Why make it easy on them?

[n_K]

If they get access to your web server chances are they'll get access to your database server.

If you think that just because one server itself doesn't have the internet makes it untouchable, you've got a lot to learn. A very early example of netcat was exactly that, hack a web front end, put a netcat remote listener on and then you do what you want to the database server as if it was on the internet.

[n_K]

Just FYI PHP 5.5 has a new password hashing API;

http://www.php.net/manual/en/function.password-hash.php