Jump to content

Question

Posted

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

Share this post


Link to post
Share on other sites

56 answers to this question

  • 0

Posted

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?

Share this post


Link to post
Share on other sites
  • 0

Posted

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.

Share this post


Link to post
Share on other sites
  • 0

Posted

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

Share this post


Link to post
Share on other sites
  • 0

Posted

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?

Share this post


Link to post
Share on other sites
  • 0

Posted

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.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0

  • Recently Browsing   0 members

    No registered users viewing this page.