Using Hash and Salt with MYSQL table

Question

I have a MySQL 'users' table with the following columns: uname , hash, salt and pwd. I'm testing a PHP log in page that uses this table to gain user access. I don't yet have the system setup to register users at the moment so testing by adding data manually to the table with the following.....

uname: 'testuser',
pwd: 'password'

the php function that deals with checking the password is below:

function checkPwd($uname, $pwd){
    // Get the hash and salt for this user:
    $q = "SELECT hash, salt FROM users WHERE uname = '".mysql_real_escape_string($uname)."';";
    $res = mysql_query($q) or die("Could not retrieve user login data " . mysql_error());
    $tmp = mysql_fetch_assoc($res);
    $hash = $tmp['hash'];
    $salt = $tmp['salt'];
    // Hash and salt $pwd so we can make a comparison:
    $hashedInput = sha1($salt . $pwd);
    if($hash == $hashedInput) return true; // Return true if the hashed and salted $pwd matches DB entry
    return false;
}

Its not working obviously, the thing is I'm not really understanding the hash and salt way of doing things. How can I test my log in page keeping things secure with the function above. Do I have to enter anything in the salt and hash fields?

Answer 1

The purpose of using a cryptographic hash function is that the values created by those functions are not reversible. So if someone has the hash of a password, there is no feasible way determining the password other than brute-forcing it.

However, there are some techniques that can subvert brute-forcing by making a time/space tradeoff using precomputed lookup tables. These can be simple lookup tables of already known hash → password pairs. Or an extended type of such a lookup table, a so called Rainbow table.

This is where the salt comes in. It is used to add additionally entropy to the user’s passwords so that each input to the hash function is unique and thus creating a unique hash as well: password will most certainly be already in the lookup table, however, xi2B9LMweH/jM8Khxedls+password certainly won’t. And due to the way Rainbow tables are constructed, an attacker would need to construct one Rainbow table for each unique salt.

Note that the purpose of a salt is only to defeat such lookup table attacks. One can still do a dictionary attack if the salt is known, or a brute-force attack anyway. If the password is bad, it can still be guessed or brute-forced.

Now as for the implementation part, it’s better not to reinvent the wheel. So have a look at Secure hash and salt for PHP passwords and How do you use bcrypt for hashing passwords in PHP?.

Answer 2

I don't yet have the system setup to register users at the moment so testing by adding data manually to the table with the following...Its not working obviously,

What about it is not working? For your function to work you need to insert a value into hash that matches your salting method (the sha1 line).

the thing is I'm not really understanding the hash and salt way of doing things.

The purpose of a salt is to make the resulting hash value "unpredictable". A hash is one way, but hackers use hash dictionaries to identify passwords with brute force (Rainbow table).

A salt can be stored in your database along with the hash - it doesn't need to be secret. However, it would be rather trivial for an attacker to regenerate their dictionaries knowing the salt. That's why it's better to use methods like Scrypt. Scrypt requires significant amounts of CPU time and memory to compute a single hash.

An Scrypt hash could be configured to take 100 ms per hash. This means you could generate 10 hashes per second. Regular hashing methods, like SHA1, are built for speed. For example: With Bitcoin mining (which uses hashing) you can produce 5,000 Mega-Hashes-Per-Second with hardware for as little as $300. GPU's are also good at computing hashes. Methods like Scrypt are ideal for protecting passwords because they are hard to brute force.

How can I test my log in page keeping things secure with the function above. Do I have to enter anything in the salt and hash fields?

Yes you need to enter a value into the hash column. It seems like you need to do more work before you can test any logins.

Since you are unfamiliar with these topics, I would highly suggest using a common PHP framework that would handle these kinds of things for you. At the very least examine how these frameworks implement authentication. Security stack exchange is also a good resource.

Answer 3

You only need "salt" and "password", the role of Salt is to create a random string value to use it like a public key to crypt the password with it.

For Example: $salt = base_convert(sha1(uniqid(mt_rand(), true)), 16, 36);

Now you can crypt your password with this Salt : $pwd = sha1($salt . $POST['pwd']); and then you save $pwd and $salt in the Database.

Now if you want to check for the login in: you do a SELECT query for a unique value (email, username) from the Database, then you crypt the entered password by the solt and test.

Edit:

For the Salt line: we create a random value for the uniqid (php.net/manual/fr/function.uniqid.php) between any couple of numbers you like I choose 16 and 36, Then sha1 to make it stronger and finally we clean up our Salt with php.net/manual/fr/function.base-convert.php

Hope it help.

Answer 4

Standard password security method is this:

Your server-side database should store two columns for each user: username and hash. If you want to use a separate salt for each user, then it can be stored as well. It's simpler to have a single salt for the site and include the username in the hash. If you don't want to include the username in the hash, then a separate salt for each user is recommended (it can be computed from the username and something site-specific if desired or cah just be random).

Most important point: passwords should NEVER be stored in a database, ever.

When the user signs up and chooses a password, build a string from the password + salt + username (or password + unique salt if you're going that route), then run this through a cryptographically secure hash function. MD5 is outdated and not very secure. SHA1 is probably fine. SHA256 would be better. Don't use a block cipher AES--these are not designed to be collision-resistant. Store the result of this hash in the table.

When the user logs in next time, take his username and password, add your salt, and compute the same hash function. Compare that to the one stored in the database. If they match, let her in. If you do this right, even if your database gets published, no one will be able to use it find anyone's password.

For extra security (probably overkill for now if you did the rest right, but good for future-proofing), use a hash function that is deliberately slow and complex to calculate. One way to do that is to simply iterate your hash function a few hundred times. Another is to use a memory-hard problem like scrypt.

The purpose of salting is to prevent "rainbow table" attacks, where potential attackers pre-compute hashes of billions of potential passwords rather than having to break them individually by brute force.