Alex Rivera | Logout

How to choose a salt for a hash function meant to protect passwords?

Asked 2010-09-23T21:04:30.600
19

I'm a (near complete) beginner, and this is my first foray into encryption - in fact this is probably the first time I use the word.

Here is my question: For a non banking / military, or even commercial, web app, what is the right way to choose a salt for a hash function used for passwords?

I can easily generate a pseudo random salt for each new user, and append that salt to their pw before applying the hash function. But I still need to store the salt so presumably anyone who gets access to the hashed passwords also gets the salts.

Is the benefit of the salt simply to make the pw "more random", and therefore defeat the standard dictionary-based rainbow tables?

Would any of the following be good & practical ideas:

  1. Store the salt in a separate db - maybe a separate system, definitely a different host, name, pw, etc.
  2. Generate the salt based on a hash of a user name (or first+last name, or sign up date), presumably using a different hash function? Then the salt itself would not be stored in the db - only the data used to compute it would...
  3. Store in the db a value which concatenates the hashed pw and the salt, in a non obvious manner (e.g., the salt is 10 random keys, and they are injected inside the hashed pw between letter numbers 1&2, 4&5, 8&9, etc).

As a side question, how easy is it to change a salted hash algorithm when upgrading the software of the website? It feels nightmarish right now.

security encryption hash
Edit
Report

1 Answer

9

Yes, the salt is just there to prevent rainbow attacks on the hashed passwords. Generally I use a single salt value for all passwords. It's stored in my source code or configuration, so it's not in the database. But it's probably better to use a different salt for each user. That way, two users with the same password will not get the same hash.

You can simply store the salt in the database along with the password. The object of the salt is that you cannot precompute a rainbow table. It would take too much time. More time than simply brute-forcing the password directly. Even if the salt is known, the complete rainbow tables for that salt would have to be generated which is extremely expensive to do. So, it does not matter much if the salt is known.

It does not matter much how you pick your salt as long as you make sure that it's long enough. According to Wikipedia a 12-bit hash (used by old unix passwords) is extremely expensive to defeat but possible. 128-bit (as used by e.g. MD5) is too expensive to defeaut in the foreseeable future.

See also: http://en.wikipedia.org/wiki/Rainbow_table#Defense_against_rainbow_tables

answered 2010-09-23T21:18:33.830

Your Answer