RE: Values to use for a salt?

> From: Craig Minton [mailto:CraigSecurity@xxxxxxxxxxxxx] 
> Sent: Monday, December 15, 2003 2:32 PM
 
> 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.

Well, it increases the computation and storage requirements for creating a
precomputed dictionary, and the search space for using it.  Whether it's
"infeasible" depends on how large the salt is (and whether it's harvested
before or after computing the dictionary) and what resources the attacker
has.

> 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.

First opinion: random salt isn't hard.  It doesn't have to be a
cryptographically-strong random value, so long as it's unbiased (so the
attacker can't guess it before harvesting).  You'd need to show a compelling
advantage to using a nonrandom salt.

Second opinion: Salt is unnecessary if you require strong passphrases.  They
already have the advantage of being too large to precompute.  Salt's only
handy when you allow short passwords.  If you're going to create a new
passphrase-based authentication system, why not make it strong to begin
with?

Third opinion: Using the password as salt is useless.

For salt to be effective, it has to force the attacker to compute a larger
dictionary than just the dictionary of likely passwords.

VNC 1.0 authentication apparently used a fixed salt for all passwords
(according to a post on vuln-dev or sec-prog years ago).  That's useless:
there are still just as many entries in the dictionary, because they all
have just one possible salt value.

If the password is also the salt, then there are ... still the same number
of entries in the dictionary.  Instead of computing the hashes of

        aardvark
        aardwolf
        aback

he computes the hashes of

        aardvarkaardvark
        aardwolfaardwolf
        abackaback

and so on.

> 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?

The replacement technique doesn't add any strength.

>  This way, the salt would not have to be 
> stored because it would be a derivative of the password.

Any time you see "the salt would not have to be stored", ask yourself "would
the attacker have to store the salt?".  That's the whole point of salt,
after all - to add work for the attacker.  If you don't need to store the
salt, chances are neither does the attacker.

> 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? 

User IDs probably have a smaller domain than you want for salt.  Computation
and storage resources are very, very cheap and very, very abundant these
days, compared to when, say, the Unix password system was developed.  The
last authentication system I threw together - which was not intended to be
especially secure - used 48 bits of salt.  I doubt there are 48 bits of
entropy in most of the user IDs or names you're likely to encounter.  That's
one problem.  The attacker may be able to harvest them ahead of time.
That's another.  Many important user IDs or names are well-known (eg root /
0 on Unix, Administrator on Windows), so the attacker can precompute a
dictionary using those.  That's a third.

In short: if you can, build an authentication system that's strong enough to
not need salt.  If you can't, use a generous amount of random salt and store
it with the password's hash.

-- 
Michael Wojcik
Principal Software Systems Developer, Micro Focus