Password encryption, SHA1() or ?

[Conjurer]

I am reworking some code from a password authentication I did a long long time ago.  The original code is using SHA1() function to encrypt the passwords for storage in the MySQL database.

 

Is that still considered the way to go, or should I be using a different method for encrypting the little buggers?

 

Thanks

[rwwd]

hash('SHA512', $data) is seeming to be a good alternative nowadays as md5 was hacked a while back, just use hash_algos() to see what you have for use, I just default to hash('SHA512', $data);

 

Rw

[Alex]

...md5 was hacked a while back...

What...?

[Mchl]

I will argue that for storing passwords in database a well salted MD5 hash is more than enough.

[rwwd]

...md5 was hacked a while back...

What...?

 

From what has been documented recently, md5 is now considered a lot less secure than it used to be, unless you salt it of course.

 

But from things I have read, it seems that hash() with your chosen algorithm is a preferred option.

 

If I am wrong on this please correct me.

 

[EDIT:] I am only offering an alternative here, md5() still functions, and as long as it is salted it is great as an encryption function - I have just taken to using hash() as a personal preference..

 

Rw

[Alex]

Yes, it is true that it has been proven that md5 alone can be less secure due to hash collisions, but I think it's misleading to just say "md5 was hacked". And I have to agree, using md5 with a salt should be secure enough. You should be salting your hashes regardless of what algorithm you're using.

[Mchl]

Also you need to consider what applications it is not secure for. It surely is no longer secure for signing douments (or files in general) since as it has been noted, it's currently fairly easy to create a file that with different content will result in same hash.

 

On the other hand we have md5 used to 'encrypt' (notice the quotes) passwords in the database. If a third party actually has access to hashed passwords, it means your site has been already compromised, and this encryption is only to protect your users' data (since people tend to use one password for all their sites). That's why we use salting to make it difficult to find original password from the hash using rainbow tables. Even if offender will find a string resulting in same md5 hash, other sites usually will use different salt/salting method, so this information will be useless.

 

[added]

 

Of course there is no harm (on contrary) in using stronger hashing functions. Just don't get too far (and SHA512 is going to far IMHO)

[rwwd]

^^^

point taken, I hadn't thought about it like that.

 

@ Conjurer, I do hope that this has shed some light on your question, I certainly have been given a new perspective...

 

Rw

[Conjurer]

Boy, that is way deeper than I can assimilate.  It is a membership area for a professional association.  So my old work was to use SHA1()  to encrypt and store the password. 

 

Is that probably good enough or should I seriously be using something else?

 

Looking for real world practice here...if it isn't broke then I would prefer to not mess with it. 

 

[Colton.Wagner]

Before I started using salted hashes I used to use:

 

sha1(md5($string))

 

I don't really know how much security that has but it worked.

 

Thanks,

Colton Wagner

[Conjurer]

Well is there a need to do something more than sha1?  Why do a md5 inside the sha1???!

 

This site just has things like bylaws and meeting minutes and names/addresses.  What I am really wondering is whether there is a compelling reason to change the sha1 encryption I am using.  If it ain't broke....

[objnoob]

Pour that SALT! 

[Colton.Wagner]

I agree with objnoob just salt it to be safe.

[rwwd]

Before I started using salted hashes I used to use:

 

sha1(md5($string))

Thanks,

 

Colton Wagner

 

 

What a waste of parser power, 1 call to md5() salted is plenty.

 

In answer to @Conjerer, md5() with hash is perfectly fine for your requirements, I would even hazard the suggestion that your sha() is ok, but so long as salt is done, as this gives you the extra little bit of uniqueness.

 

Rw

[Conjurer]

So it sounds like I need to modify the function since I am not adding SALT except on my food. 

 

Here is the code I came up with for changing password.  I am not sure how to SALT it and will research that in the reference doc, but given that I have to modify it to add SALT - should I change to something else?

 

 

//---------------------------------------------------------------------------
// function to change user password
//---------------------------------------------------------------------------

function change_password($username, $old_password, $new_password)
// change password for username/old_password to new_password
// return true or false
{
  // if the old password is right 
  // change their password to new_password and return true
  // else throw an exception
  $conn = db_connect();
  assert ($conn);
//  echo "login parameters for the change_password function:<br>";
//  echo "User = $username, Password = $old_password, Connection = $conn<br>";
  login($username, $old_password, $conn);
  $result = $conn->query( "update users
                            set password = sha1('$new_password')
                            where username = '$username'");
  if (!$result)
    throw new Exception('Password could not be changed.');
  else
    return true;  // changed successfully
}
//---------------------------------------------------------------------------
// function to get random word

 

Suggestions on how best to modify the encryption would be appreciated.

 

 

Thanks for the help.

[Conjurer]

Hmmm, not finding much on SALT and how to.  There were two recent approaches at the MD5() documentation discussion. 

 

Are these both pretty much the same or would one approach be better than the other?

Very ugly way to combine.

<?php

$salt = md5("1234567890ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz");
$password = hash( 'MD5',$salt );
$hash = $password . $salt;
$rand = rand(1, 256)%4;

for ( $i = 0; $i < $rand; $i++ ) {
  $hash = hash('md5',$hash );
}
echo $hash, '<br>';
echo (microtime(1)-$time)*10000,': time in ms';
?>
Anonymous
08-Jun-2010 08:36
Here's a relatively simple function I designed to hash out passwords using MD5.  Assumes max length of user supplied password (20) max length of database field (40).

<?php
define ('SALT_ONE', 'some_random_123_collection_&$^%_of_stuff');
define ('SALT_TWO', 'another_random_%*!_collection_ANbu_of_stuff');

$password = 'dragon';

function generate_encrypted_password($str) {
$new_pword = '';

if( defined('SALT_ONE') ):
   $new_pword .= md5(SALT_ONE);
endif;

$new_pword .= md5($str);

if( defined('SALT_TWO') ):
   $new_pword .= md5(SALT_TWO);
endif;

return substr($new_pword, strlen($str), 40);
}

echo generate_encrypted_password($password);
?>

[Mchl]

Keep it simple

<?php
$salt = "%YNbev346$#2@#bYBU%#m573v5N^U*"; //generated by randomly bashing head on the keyboard
$password = "mary"; //supplied by user
$hashedPassword = md5($password.$salt);

[naike]

One question here.

Would this be a viable salting method.

Taking the username, adding it to the password and then hashing it.

<?php
function salt_hash($password, $username) {
        $result = hash(sha512, {$password} . {$username});
        return $result;
    }
?>

If the database was compromised, the hacker wouldn't know that the salt was the username.

Any ideas? or other suggestions, on a detailed method on how to execute the salting procedure.

I can't think of any since I'd have to save the salt into the DB aswell (when logging into the site, it compares the hashed passwords).

[Mchl]

If the database was compromised, chances are that the offender has access to your script as well. Never rely on that. Adding a username to password will obviously make it harder to 'crack', but a long randomly generated salt is a better solution. You can still combine the two.

[Conjurer]

Keep it simple

<?php
$salt = "%YNbev346$#2@#bYBU%#m573v5N^U*"; //generated by randomly bashing head on the keyboard
$password = "mary"; //supplied by user
$hashedPassword = md5($password.$salt);

 

I like simple!  Thanks - back on track now. :-)

[naike]

If the database was compromised, chances are that the offender has access to your script as well. Never rely on that. Adding a username to password will obviously make it harder to 'crack', but a long randomly generated salt is a better solution. You can still combine the two.

Good, I was about to ask if it was possible that the script itself could get compromised.

However, your salt function does essentially the same as mine, just takes the salt from the script, making it just as "secure"?

Or am I missing something.

Because if I understood your correctly, I'd have to use a salt, that is randomly generated, but to check if the password matches when logging in, I would have to store the salt to the user table too, because each and every user has a different salt. Otherwise they can't log in because the passwords don't match.

[Mchl]

I don't really feel competent enough to explain it in full detail, so I'll need to refer you to http://en.wikipedia.org/wiki/Salt_%28cryptography%29

perhaps the most important sentence in this article is:

each bit of salt used doubles the amount of storage and computation required.