Re: Values to use for a salt?

>My understanding is that salts are used to help deter dictionary attacks where the attacker has cr
eated a pre-hashed list of passwords and comparing them against the actual hashed passwords.  Using
 salts means the attacker must compute all possible values of the password in the dictionary plus b
y the possible salts, which makes it computationally unfeasable.
>
>Someone suggested recently of using the password as the salt.  I have never seen this discussed be
fore, and would like to get opinions of it.  What would be wrong with this, especially if it were a
ltered in some way before being used, such as using a simple replacement table to change letters to
 special characters?  This way, the salt would not have to be stored because it would be a derivati
ve of the password.  How would this differ from the traditional approach of generating a random sal
t and storing with the hashed password?

It would completely defeat the purpose of the "salt" as there would be
only one way in which a password could be stored.

>Also, how much less secure would it be to use a user ID as the salt instead of a random salt that 
then has to be stored?  I've been thinking about these, but feel I am missing important ideas.

It would hinder the precomputation step; the randomness of the salt is not
that important, the spread around the user population generally is; the
current standard password salt is too small with 12 bits.  A user 
name based salt would allow for many more different values.

(The Solaris pluggable crypt(3) implementation passes the username to the
crypt_gensalt() routine specifically so that a different password 
encryption algorithm can use the username as salt)


Casper