RE: Values to use for a salt?

My opinion is that it's a bad idea.  I haven't a lot of expertise
in this area, and it's possible that I don't understand what you're
proposing, but it seems pretty weak.

If the password itself is going to be the salt then there is no
additional informatioin being used in the generation of the hash.
Even if you have some constant transformation of the password to
yield the salt as you describe, you have the same weakness to a
dictionary attack as an unsalted scheme.  The dictionary attack
would just take each entry in the dictionary, copy the entry into
the salt and then generate the hash.

The idea of using the userID as the salt seems slightly better than
using the password, but only very very slightly.  It seems to me
that it is only an improvement if the user ID is not known in advance.
But, userIDs are one of the things that are "published", at least by
Sun's NIS.  Also, pretty much everyone knows that the root uid is 0 so
the attacker would always know the user ID of his most coveted target.
Finally, the userID doesn't change.  Every time the target changes his
password he'd be using the same salt.  The attacker only ever have to
generate his list of hashed dictionary entries once.  There is no
gain in security from using the salt in that case.

But, maybe I misunderstood the point of your proposal.


Breck 

-----Original Message-----
From: Craig Minton [mailto:[email protected]]
Sent: Monday, December 15, 2003 11:32 AM
To: [email protected]
Subject: Values to use for a salt?


My understanding is that salts are used to help deter dictionary attacks where the attacker has created 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 by the possible salts, which makes it computationally unfeasable.

Someone suggested recently of using the password as the salt.  I have never seen this discussed before, and would like to get opinions of it.  What would be wrong with this, especially if it were altered 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 derivative of the password.  How would this differ from the traditional approach of generating a random salt and storing with the hashed password?

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.

Thank you for any thoughts you can give.

-Craig


_____________________________________________________________
Fight the power!  BlazeMail.com