The link: http://www.webmaster-talk.com/php-fo...ht=store+salts is really informative. But I wonder: Where do you store the salts. If they're randomly generated, we can't reproduce the same ones at every user's login. So where and how do you store them?

Thank you,

matt w

I like to generate them, from a mathematical formula over, say, the user ID.
It can fairly simple, but it will give a different one for each members of your tables, making it way harder to breach.

Why not simply take the ascii value of the character and multiply it by pie (pi, py, pye ??? 3.1416 !!!).
This alone is simple and don't need anything stored anywhere.

Tripy, I know you get it, but I still can't wrap my mind around it. Please let me think outloud:

I generate a unique random string which I will use as the salt. --One unique, permanant salt for every user that registers on my site-- I store the salt somewhere, in plaintext, where I can get at it with my php. Somehow every salt must be indentified as belonging to its user. I also accept from each user their username and password. My php script then joins their plaintext password and plaintext salt, hashes it, and stores it in the database. Essentially that is their password, the salt and password concatenated and hashed and stored in the db.

The next time the user logs in, I use their username as a reference to find their plaintext salt. I append the plaintext salt I just found to the plaintext password they just gave me, then hash it.

I check the hash I just created with the stored salt&password hash I have in my database, and if the two match they successfully log in.

Thats how I think it would go.

Where do I store the plaintext salt? The salt must be unique and permanent for each user or I couldn't successfully compare password + salt hashes time after time, right? The salts have to be linked to the users so I can pull the salts up when each user logs in again. But if they are plaintext and somehow identified with their user, isn't that a security risk?

Thanks tripy,

matt

I store the salt in the same file as the DB config file or a master config file depending on the software. Oh, and I store it as a variable.

I suggest not using a salt based on an algorithm as tripy has suggested. Then, the security relies on no one being able to guess the algorithm instead of no one being able to guess the salt. Encryption should not rely on methodology.

I usually just store a different salt for each user in my database. When someone punches in the cooresponding username it checks the password they gave encrypted with the salt with the one in the database.

PHP Code:

$username = $_POST['username'];
$password = $_POST['password'];

$query = 'SELECT * FROM `users` WHERE `username` = \''.$username.'\' LIMIT 1;';
$result = mysql_query($query);
$row = mysql_fetch_array($result, MYSQL_ASSOC);

$password = md5($row['salt'] . md5($password));
if($password == $row['password'])
{
     //SUCCESS
} 


I'm not sure if this is the best approach but its better than just using md5 alone. The code above is just a simplified example, obviously you should do some checks before retriving anything from the database (password length, blank or invalid input, mysql injections, etc) This is the code I use for generating md5s for each user:

PHP Code:

define("SALT_LENGTH", 3);

function createSalt()
{
    $salt = substr(md5(uniqid(rand(), true)), 0, SALT_LENGTH);
    return $salt;
} 


Hope that helps.

Simple and no need to store a salt. The salt is appended to the hashed text/password.

PHP Code:

<?php

define('SALT_LENGTH', 9);

function generateHash($plainText, $salt = null)
{
    if ($salt === null)
    {
        $salt = substr(md5(uniqid(rand(), true)), 0, SALT_LENGTH);
    }
    else
    {
        $salt = substr($salt, 0, SALT_LENGTH);
    }

    return $salt . sha1($salt . $plainText);
}

?>

PHP Code:

//hash to insert in database
$password = hashPassword($_POST['password']); //don't forget to add validation 


PHP Code:

//Sample usage:
$username = $_POST['username']; //don't forget to add validation
$password = $_POST['password']; //don't forget to add validation
$res = mysql_query("SELECT * FROM user_table WHERE username='$username'",$db);

if (mysql_num_rows($res) > 0) {
     $db_password = mysql_result($result,0,"password");
     $password = hashPassword($password,$db_password);
     $result = mysql_query("SELECT * FROM user_table WHERE username='$username' AND password='$password'",$db);
    }
if (mysql_num_rows($result) > 0) {
     //valid
} else {
     //invlaid
} 


Sorry Inet, but you should NOT append your salt to the hashed value -- that defeats the whole point.

Let me illustrate: Hash 2 texts. Compare which characters are contiguously the same. Those characters are the salt. Then a dictionary attack will allow you to find the correct password (for simple passwords).

Also, in Inet's code (again, no offense), the salt is either randomly generated (i.e. useless give the hack method I just explained) or stored elsewhere and passed to the function meaning that you still have to store it and you're back to step 1.

Now, to say something positive, wrapping the hash seed in a function is another way of solving the problem. The code would look something like this:

PHP Code:

<?php
function generateHash($plainText, $salt = 'YOUR HASH SALT HERE')
{
    return sha1($salt . $plainText);
    //Alternatively, you could use a "stronger" hash function
    return hash('SHA512',$salt . $plainText);
}
?>

Mr. Miller, I understand what you are saying. You must try a dry run through the code though. You will see the hash (which is random each time) will not be the same when you hash 2 texts, so you will not be able to compare similar characters. But, if someone knew the salt length '9' in this case and the method of hashing without knowing the salt, it could still be cracked. So, in light of defending myself and my code I am currently changing my functions now to reflect the SHA512 and I am 'stealing' your posted code Thanks,
Rob

Good point Rob. You're right there -- they would have to know the hash length. That wasn't immediately obvious to me when going through it the first time. The user would then need to have a clue about the hashing function (or write a brute force script -- not too much harder than writing a dictionary script given that hashing functions are well known and their lengths are known).

One note for everyone: hash functions are not permanently secure. 5 years ago, md5 was fine, but now 2 inputs with the same output have been found; same deal for sha1; same deal for any hash given enough time. Using a salt SIGNIFICANTLY increases the security, however.

Thanks for the correction Rob.

EDIT: I make "brute force" and "dictionary" hacks sound easy -- they are fairly easy to code, but that doesn't mean they solve the problem quickly; they could take years of work. In fact, the CIA uses such attacks by indexing every word on your computer and every word on every website you've visited and uses every computer in their system (including desktops) to try every possible combination of found words to try and hack you. That ends up being a LOT of computing power (think of the SETI screen saver program), but even then things take time.