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