RE: Values to use for a salt?

I have watched this thread with some interest and I wanted to clear up 
some misunderstandings of salt, hashes, and HMACs (and maybe also plug 
my upcoming book "Hacking the Code" from which this is derived):

First of all, the purpose of a salt is to provide randomness for 
hashes so that the same password doesn't always produce the same hash, 
forcing the attacker to compute the hash and preventing pre-computed 
hash attacks or known-plaintext attacks. Therefore a salt must meet 
these two requirements:
1. The salt must produce enough hashes for any given password to 
prevent the attacker using a dictionary of pre-computed hashes.
2. The salt should be unique for each user with few collisions.

Deriving the salt from the username does produce multiple hashes for 
any given password and does provide uniqueness for each user within a 
single system but not across multiple systems. Therefore someone could 
build pre-computed dictionaries for common users such as root or 
administrator. You should not derive the salt from the username.

Deriving the salt from the password does not produce a unique hash 
because a password salted with itself can still only produce one 
possible hash. You should not derive the salt from the password.

A large random number for the salt provides a huge number of possible 
hashes for every password and provides enough key space to ensure 
uniqueness, even across multiple systems. When creating salts for 
storing hashes for authentication purposes the generally accepted 
method is to generate a large random number and there is little reason 
to come up with a new scheme for creating salts.

Note that there is no requirement to keep the salt secret because 
knowing the salt does not gain the attacker the benefit of not 
computing hashes. We assume here that the hashes themselves are at 
least somewhat protected. Generally if the attacker has access to the 
hashes the attacker also can gain access to the salts no matter what 
scheme you use. Therefore, storing the salt along with the hashes is 
acceptable and still meets the requirements of a salt.

Now there are situations where you must transmit a hash across an 
insecure medium and therefore risk exposing the hashes to attackers. 
In these cases you use a keyed hash, or HMAC, which is technically the 
same as a salt but in practice is different because you must now 
protect the key itself rather than the hash. 

With a key you have further requirements:
1. You must use a strong random number generator for the key.
2. The key must utilize a large enough key space to prevent a brute 
force attack.
3. The key must be protected as a secret.

So it is important to distinguish between salts used for storing 
password hashes and keys used for transmitting hashes across an 
insecure medium. A salt adds randomness to a hash and does not need to 
be kept secret and can be stored with the hash. A key protects a hash 
and should always be kept secret.


Mark Burnett