Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email firstname.lastname@example.org
Re: Values to use for a salt?
From: Scott Cleven-Mulcahy (scottcm3hotmail.com)
Date: Thu Dec 18 2003 - 18:12:42 CST
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
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
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
Have fun customizing MSN Messenger — learn how here!