un-md5 something

[Naez]

I'd recommend a random salt, stored with the password.

 

A static salt can be found easily if multiple hashes become compromised.

 

Do you mean store a row in the database for unique salts per user?  I was going to do something like that for a user system I'm writing.

 

<?php
function saltgen($length=10)
{
$out = null;
    $letters='abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789';
    for($i=0; $i<$length; $i++)
{
        $out.=$letters{rand(0,61)};
}

return $out;
}
?>

[peranha]

I'd recommend a random salt, stored with the password.

 

A static salt can be found easily if multiple hashes become compromised.

 

this can be found easily as well if they get your database, or however you store passwords.  But yes, Rainbow tables can be made easily for sha512.

[Naez]

Realistically, if someone gets a dump of your database you have bigger problems than encryption imo

[MadTechie]

<?php
function hash_password($password)
{
$salt = "m2cCksLreG12";
$pass = $password;
for ($i=0; $i < 10; $i++){
	$pass = sha1(md5($pass . $salt));
}
return $pass;
}

echo hash_password("supersecret");   // a3400f8e72116cba59ab23bd1974b565a31e13b9
?>

 

erm i think your find that sha1(md5($pass . $salt)) will be less secure than sha1($pass . $salt)

since you're feeding in 128-bits of information to generate a 256-bit hash, so 50% of the resulting data is redundant.  You have not increased security at all.

 

EDIT:

Also rainbow tables can be made for anything if you have the right data.. its not a point of if a rainbow table can be created its if its worth it.. of course a static salt means a rainbow table can give you everyones password on that site but dynamic salts means rainbow tables are more or less useless..

 

 

EDIT2:

just as a side note everyone and their dog can create "super-secure" functions for hashing and re-hashing passwords but its performance as well, looping 10 times i don't think is a great idea your create more collision.. again less secure..

 

if you want to make it harder to break try add 2 salts and do something with them,

or even 8 char salt, hash that and use the first 16 chars appended or prefixed to the password before hashing it..

[discomatt]

Realistically, if someone gets a dump of your database you have bigger problems than encryption imo

 

Exactly.. the idea here is to protect the user from someone grabbing a hashed password on the way to the server. If they get your db, i think the user/password hashes are the least of your worries.

[deadonarrival]

My process (when I'm feeling very paranoid, eg on eCommerce sites - less effort is put in when it's an RPG for example), with the idea of making it a bit random (ie the process isnt likely to be guessed by someone who only has a list of hashes) without compromising too much a) processing power - don't want the script to take an hour to parse and b) database storage

 

Choosing numbers 0-10000 and adding them to the front of a dictionary attack is 5,000 times more effective (based on average time until the correct number is hit) security then with no hash.

 

So I generate a 6 digit number (100,000 to 999,999) this is stored in a char(6) field in mysql - saves a lot of space over storing the 32 bit hash

This is split in half, and put together again in reverse order (ie 123,456 becomes 456,123)

It's then md5'd (much less space than sha512, my main encryption and faster)

 

Again this is split in half, and the front half put in front of the password, the back half behind it.

Finally I hash this concatenated string, and job done.

 

Yes, slower than sha512 - but like I said, it's used only on sites I'm feeling ultra secure on, and since it's only used on registration and once per log on, so although it's slightly more processing overhead, I'm willing to make the sacrifice, and in terms of storage it's only 6 chars on top of the 128 of the final hash.

 

To Naez - if someone got into my database, I would be very worried - and hopefully they can't ever get there... but for me, the customers privacy is a major concern if the database does happen to be breached. Any sensitive data I encrypt in some manner. Customer trust is a major factor - if it was revealed that Amazon had been hacked and hadn't bothered encrypting the passwords, they'd lose a LOT of customers. Trust is a lot in eCommerce... the more encryption the better