If your system already has some other unique user identifier (be it an ID, user-name, or an EmailAddress) is there any effective decrease in your security if you simply use that value as your salt?
The salt in a hash actually forms two different purposes. Generally, it is acceptable for a salt to be known, so let us consider
H() a hash function,
S, some data and
P something to protect. From this information we store
S. There are two consequences for the attacker in generating a rainbow table for
- Either they can generate a huge rainbow table for the entire set of possibilities that might be
S+P. The longer the data you wish to reverse in a hash, the larger the data storage requirement of the rainbow table, so extending the length of the hashed data makes it infeasible to reverse the hash by generating a generic rainbow table.
- The attacker can generate a rainbow table for the specific fields of input missing for a specific salt. Clearly, the usefulness of a rainbow table is then restricted to a specific set of hashes to attack, since in theory all other hashes should be useless.
In the case of 1) anything you add as salt will do, quite literally. The problem is the case of two. The reason for using unique, random salts is that the chances of colliding salts for a specific hash output are vastly reduced. For example, hashing
userid:fred:myotherpassword, a rainbow table generated knowing the salt
userid:fred and the correct construction of the hashed text would work across both cases.