Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Hashing and salting values

I am developing a small web app that internally authenticates users. Once the user is authenticated my web app then passes some information such as userID and Person's name to a third party web application. The third party developer is suggesting that we hash and salt the values.

Forgive my ignorance, but what exactly does that mean?

I am writing the app in Java. So what I am planning on doing is hashing the userID, Person's name, and some Math.random() value as the salt with Apache Commons Digest Utils SHA512 and passing that hashed string along with the userID and person's name.

Is that the standard practice? I should be passing the third party the salt as well correct?

like image 752
Avanst Avatar asked Jun 03 '10 21:06

Avanst


4 Answers

A salt is normally used for storing hashes of passwords safely. Hashing a password for storage or communication (such that it can't be read by others) is vulnerable for decoding by using rainbow tables. Now, when you add a random string to the password, but store the string with the hash, this becomes much harder. Calculating this new hash looks like:

hash(password + salt)

or even

hash(hash(password) + salt)

To safely log into a third party website, can send the UserID, salted hash (from above) and the salt that you used (if it is not given). Depending on how that website stored its passwords, you can generate the salt for yourself or you can ask for a salt from it.

One option is to send the UserID first to the website, then let it respond with the salt, and then send the hash(password+salt)) back to the website.

like image 63
Marc Avatar answered Sep 25 '22 06:09

Marc


In Java you can do something like:

import org.apache.commons.codec.digest.DigestUtils;
import org.apache.commons.lang.RandomStringUtils;

/**
 * SHA1-hash the password with the user's salt.
 *
 * @param password
 */
public void setPassword(String password)
{
    if (password.equals(this.password))
    {
        return;
    }

    if (passwordSalt == null || passwordSalt.equals(""))
    {
        passwordSalt = RandomStringUtils.randomAscii(20);
    }

    this.password = DigestUtils.shaHex(password + passwordSalt);
}

/**
 * Check if a given password is correct.
 *
 * @param givenPassword
 * @return True is correct, else false.
 */
public boolean checkPassword(String givenPassword)
{
    return (password.equals(DigestUtils.shaHex(givenPassword + passwordSalt)));
}

Then the password is not readable, even if a hacker steals your DB.

like image 25
Amy B Avatar answered Sep 22 '22 06:09

Amy B


Just a heads up, there is some misinformation out there on what to do with the Salt. It IS ok and normal to store the salt. Each password should have its own salt that is stored in plain text along with it. It is meant to make it a lot harder for someone who has already stolen your hashed password database to de-crypt it using a pre-calculated hash table.

As far as if you should be sending the third party the salt, I'd have to have a little more information. Whoever is taking the client-supplied password during authentication, hashing it and comparing it against the pre-hashed version needs the salt so that the password that the client supplies for authentication can be hashed exactly the same as it was before.

like image 42
Chris Dutrow Avatar answered Sep 22 '22 06:09

Chris Dutrow


Once the user is authenticated my web app then passes some information such as userID and Person's name to a third party web application. The third party developer is suggesting that we hash and salt the values.

That doesn't sound right. Hashes are one-way operations. You can't take the result of a hash and divine the plain text from it

What I am planning on doing is hashing the userID, Person's name, and some Math.random() value as the salt

For any given plaintext, you need to use the same salt or else the resulting hash will be different. So if you're going to use a random or generated salt, you need to store it along with the password hash.

Using SHA-256 or SHA-512 is fine and is what NIST recommends

like image 29
Kevin Avatar answered Sep 25 '22 06:09

Kevin