Re: Values to use for a salt?

Brian
thanks for correcting my overly broad statement that salt must be secret - 
there are definitely situations where salt is not secret.  Incidentally, 
Windows 2000 and later (not sure about NTLMv2 under NT4) use a method other 
than salt to provide uniqueness and randomization.

Still, the point remains that salt can provide two functions: increased 
randomness and uniqueness of a password's hash.  Highly random salt, if used 
for all password's, only increases the randomness of a password.  It does 
not solve the uniqueness problem - two people with the same password would 
still have the same password hash code.  To make the point more relevant, 
consider authentication for a web application.

My first suggestion is to either purchase or use a well known open source 
package.  This stuff is hard and amateurs like myself will probably screw it 
up.  Still the need arises, it's good to be familiar the techniques, and 
this is a security programming mailing list.

In a web application the username and password is often sent to an 
authenticating system, which then hashes it.  The client should not be 
trusted to perform this function.  The authenticator needs to store a 
mapping of user names to hash codes (storing raw passwords is discouraged).  
In this case, the salt should be highly random, but possibly not unique per 
user.  Protection of each user's hash code becomes important to prevent 
birthday attacks, which diminish the effective strength of a hash.

Since the password hash is normally protected, why would you want to use a 
unique salt?  Layered security.  In the event that the password hashes 
become exposed, a birthday attack can be used to decrease the effectiveness 
of the hash.  The secrecy of the salt will also assist in protecting the 
passwords.  The problem is that now you must map username to password hash 
to salt.

Another possibility would be the following.  A mapping table with the hash 
of the username as the table's key, the username, and the user's encrypted 
password hash code.  The hash code is encrypted with the authenticator's 
asymmetric public key.  The authentication process now looks like this:
1.  Hash the username
2.  Hash the password with salt.
3.  Do a table lookup using the username hash code as the key and retrieve 
the encrypted password hash code
4.  Unencrypt the password hash code using the authenticator's private key
5.  Compare the password hash codes
6.  If the password is being changed, hash the new password, encrypt it with 
the authenticator's public key, and write it into the table.

Now, if the user database is compromised the attacker needs the 
authentictor's asymmetric private key before they can begin to brute force 
the password hash codes.  If the salt value is unique per person then the 
attacker can't compare hash codes to identify identical passwords.  Could 
the salt, or HMAC key, be the hash code of the username?  It would provide a 
unique salt or HMAC key per user, but I don't know the security impact it 
may have.

I really need to stress that I am *not* a qualified cryptographer.  While I 
think this design can provide secure authentication, someone with more 
expertise would need to critique it.  The worst thing to do is to roll your 
own cryptography.  Use what's tried and true and tested.

Hope this helps and that I haven't digressed too much from the original 
topic.

Scott Mulcahy

_________________________________________________________________
Have fun customizing MSN Messenger ? learn how here!  
http://www.msnmessenger-download.com/tracking/reach_customize