[SOLVED] Double hashing password with salt

[hostfreak]

Hey, I have the following code:

<?php
//Password
$Password = 'Password';

//Generate random number
$Random_Num = rand(48, 122);
//Convert random number to a real character
$Salt = chr($Random_Num);

//Double hash password /w Salt
$Secure_Password = md5(sha1($Password.$Salt));
?>

 

I was just wondering how efficient it is to double hash? And if using both md5 and sha1 in conjunction like that is alright? I've seen double hashing with the same function like md5(md5()), not like the above though. Also, in general, is the above pretty sound, security wise?

[keeB]

Well your problem with the 'salting' with a random number... is, well.... how are you going to validate the password ever again?

[hostfreak]

Well, for example sakes, lets say the above was used with a user login system. I would store the salt for each user in a database. Then upon login: pull the salt & password, then validate etc.

[dbo]

Double salting is overkill. However, MD5ing a password and then using native database functions to encrypt stuff might be acceptable.

 

That being said to validate the password you'll have to store the random number in the database as well. What I've done in the past is use userid as a salt and concatenate it on either the beginning or end of the password (or both) and then hash it.

[keeB]

Ok lets talk through this.

 

Using your code:

<?php
//Password
$Password = 'Password';

//Generate random number
$Random_Num = rand(48, 122);
//Convert random number to a real character
$Salt = chr($Random_Num);

//Double hash password /w Salt
$Secure_Password = md5(sha1($Password.$Salt));

print $Secure_Password
?>

 

Refresh this page 5 times, you'll get 5 different results, right? That's bad. Your users will never be able to login

 

[keeB]

 

That being said to validate the password you'll have to store the random number in the database as well.

 

Or store the salt as well, as dbo says.

[hostfreak]

Also, the character length returned by default for both functions (md5, sha1) is different. So if I double hash using each function, both return a different length of characters. Therefore, isn't that defeating the purpose of each (when using them in conjunction with each other)? The returned character length would follow the main functions, in this case md5, correct?

[hostfreak]

So stick to one hashing function & if possible use database functions for extra encryption. Then the salt, instead of a random number should/could be a userid or something pertaining to whomever the password is assigned to and is also stored in the database? Makes sense. Then security wise, that should be pretty sound?

[keeB]

As long as the salt is 'static' <- i.e you know it 100% of the time, yes! This method works.

[dbo]

For the encryption piece it'll be pretty sound, but overall there are a lot more security considerations to think about.

[hostfreak]

Alright, so if I get rid of the double hashing and store the random salt in a database (therefore making it static, for each password), maybe some database encryption, the hash would be pretty sound then, correct?

 

Right now, I am just focusing on the hash alone.

[dbo]

Yup, you should be fine.

[hostfreak]

Alright, thanks for the help guys!