TalkPHP - Password salts

TalkPHP (http://www.talkphp.com/forums.php)

- General (http://www.talkphp.com/general/)

- - Password salts (http://www.talkphp.com/general/3006-password-salts.html)

h0ly lag

06-25-2008 09:47 PM

Password salts

So I've been looking at how to crypt users passwords. Obviously MD5, but there are rainbow tables for that among other things. I also tried hashing stuff multiple times. Like this:

PHP Code:


		
			
function pass_crypt($str)
    {
    $sha1 = sha1($str);
    $rot13 = str_rot13($sha1);
    $md5 = md5($rot13);
    return $md5;
    }

But read in quite a few different places that this is bad. But now I looked into salting the passwords. I read about using something fairly unique for the salt for every user. Like using their username as the salt. Or email. But say I wanted to use a completely random 16 char salt for every user. How do I go about storing the random salt for later use. Like when they go to log in. If I put it in the database isn't that just defeating the purpose. Because now if some hacker has my database with the MD5's and the salts to go with it they have everything they need.

Or I guess the hacker would have to generate a new rainbow table for each password because their all different salts. Right?

drewbee

06-25-2008 10:44 PM

you would first need a unique identifier for the user. Then I would try and design some type of algorithim that will return the exact same value when passing that identifier to the user.

Personally, I think a salt for each user is a little overboard. I use a salt in my passwords as well, but it is just one constant for everyone.

IE

PHP Code:


		
			
function md5Password($password)
{
    $salt = "¤G,~\YUV_M-a'~$bSvCHb{p)qOp!04B5f2$E__'4-r?%+f\9G1@";
    return md5($salt . $password);
}

Dictionary attacks are no longer a problem. The only attack you would be looking at now is a random character generator. This is why you block access to the login function of your site after 5 or so attemps and and failed password within so much time :)

Also, be mindful not to change the salt. If you do, everyones passwords will no longer work.

Also keep in mind you will need this whenever a user registers or sets a new password as well as logging in! :)

Wildhoney

06-25-2008 10:47 PM

I've addressed encryption salting here and here, if you wish to have yourself a read through :-) I would recommend that you do it, if the accounts are so precious, and especially if the website's on a shared host.

h0ly lag

06-25-2008 10:53 PM

Thanks Wildhoney, I read both of the articles and all the replies. It seems like I was already on the right track.

Anyways, here is something I pieced together with some help from Google. It will generate my random salt. Not sure why I'm posting it, figure it might help someone. Or maybe some critique?

PHP Code:


		
			
//generates a random salt for use when crypting user passwords
//includes all upper and lower case, numbers, and common symbols (no ALT code symbols)
function gen_salt($length)
    {
    $salt = "";
    $possible = "abcdefghjklmnpqrstuvwxyzABCDEFGHJKLMNOPQRSTUVWXYZ0123456789!@#$%^&*()_-+=[]{}\/.,?<>`~";
    $i = 0;

    while($i < $length)
        {
        $char = substr($possible, mt_rand(0, strlen($possible) - 1), 1);
        $salt .= $char;
        $i++;
        }

    return $salt;
    }

delayedinsanity

06-25-2008 11:12 PM

Quote:

Also, be mindful not to change the salt. If you do, everyones passwords will no longer work.

Another good reason to read Wildhoney's dynamic salt articles. I originally used a static salt with my encryption, and ran into this problem - if I wanted to change the salt, I had to write another routine just to loop through the entire table and rehash everybody's passwords. Easy enough on a test system with 20+ users, not so good on a user base of 1,000-20,000 (pretty darn easy to reach on some of todays sites).

When I switched it to a dynamic salt this became a moot point. When the user changes their password, a new salt is created, if they forget their password and need a new one emailed to them, a new salt is created, and so on and so forth. So everybody has their own dynamically created self updating salt. Makes the system more secure, and ironically simpler.
-m

h0ly lag

06-25-2008 11:26 PM

Awesome replies guys, thanks. I think I can take it from here I guess.

drewbee

06-26-2008 01:20 PM

My only issue with the dynamic salts on a per-user basis is behind the idea that it is stored in the database. However, under any circum stances should a hacker get access to your database and can view the salts...(table) I think you have much bigger problems on your hands then the user account passwords.

Thanks for the read Wild.

delayedinsanity

06-26-2008 02:05 PM

As you stated, if a hacker gains access to your database, having your salt visible is the least of your problems. However if you're still worried about maintaing security over your members passwords at this point, there are still things you can do. You can use a combination of the salt with another inconspicuous column (such as their username, or the date they registered, etc) in the hash, as well as using some random method to change where the salt is used in the hash (usernames beginning with a-m would be hashed SALT|PASSWORD|USERNAME, usernames n-z USERNAME|SALT|PASSWORD, etc).

If you want to get real crafty, and you happen to be using a timestamp somewhere in your table, pull thelast two numbers off of it and use them to chop your password in half and place the salt in the middle somewhere. PA|SALT|SSWORD or PASSW|SALT|ORD are much harder to brute force then SALT|PASSWORD and PASSWORD|SALT if the SALT is known.

This all may not stop a hacker from figuring it out, but it would definitely slow him or her right down. Again though, if a hacker has access to your user tables, how you hash should be the least of your concerns.
-m

xenon

06-27-2008 07:21 PM

People just don't go around the web downloading other people databases. Mostly because the database server is not directly accesible from the outside of the network it's running into (in most of the cases). Or at least it shouldn't be. Or say it is, then you limit the IP's that can connect to it to yours only. You can fully protect database theft using some simple security utilities. Take iptables, for example. Protecting the data in the database is a totally different issue, and that's what you need to be worried about. Because data theft is possible, via various methods: input tainting, sql injection, CSRF and such.

Jim	06-27-2008 07:27 PM

If you would use IPtables to allow only a certain IP for a database won't work if you access the database via HTTP like PHPmyadmin. With IPtables you can block incoming connections (and outgoing / forwarding) and since phpmyadmin (if used) will be localhost that won't work. So with IPtables look out since it's just a firewall :)

All times are GMT. The time now is 04:04 PM.