RE: Values to use for a salt?

> From: Scott Cleven-Mulcahy [mailto:scottcm3@xxxxxxxxxxx] 
> Sent: Friday, December 19, 2003 12:40 PM

Perhaps this is just terminological confusion, but:

> I allowed myself to digress from password salt into HMAC.  
> Also, thanks for correcting my inaccurate comparison of salt with
> HMAC.  Salt is a MAC, not an HMAC.

Salt isn't either.  A MAC is a keyed one-way hash function.  The salted
password schemes we've been discussing employ a one-way hash function, but
they're not necessarily MACs (they may be unkeyed hashes of password + salt,
for example).  More importantly, the security functions of one-way hashing
of passwords, with or without salt, do not depend on a MAC per se; they
depend on the strength of the one-way hash (which is a subset of the
requirements of a MAC).

(HMAC, defined in RFC 2104, is a particular construct that uses a one-way
hash function as the basis for a MAC.)

> FIPS 113 is one of the standards that covers MAC, and states "It is 
> therefore crucial that keys be protected so that their secrecy is 
> preserved...."  Whether it's routine or not, transmitting the 
> salt in the clear clearly doesn't preserve their secrecy.

Since password-hashing schemes don't depend on MAC behavior, this is
irrelevant.  Salt is specifically designed so that it does not have to be
secret to accomplish its intended security function.  It accomplishes that
function solely through distribution of salt values across a sufficiently
large range.

> >From: Michael Wojcik <Michael.Wojcik@xxxxxxxxxxxxxx>
> >Not unless the random salt happened to be the same for both. 
> >Ensuring unique salt does not scale well and becomes unnecessarily
> >complex

> Exactly my point.  Using the same salt over and over results 
> in the same hash code for the same 2 passwords (at least, it
> better!).  

Who was advocating using the same salt values?  My point was that random
salt is sufficient to make collisions vanishingly unlikely, and so nothing
more complex than random salt values is necessary or advisable.

> >So you're assuming an attacker who has the password hashes 
> >but not the salt.

> No, I'm ensuring that the same 2 passwords do not produce the 
> same 2 hash codes.

No, you were assuming an attacker who has password hashes but not salt
values.  Let's review.  You wrote:

> > The secrecy of the salt will also assist in protecting the 
> > passwords.  The problem is that now you must map username to 
> > password hash to salt.

The "secrecy of the salt" can only "assist in protecting the passwords" if
the attacker has the password hashes (and so can try to brute-force the
passwords) but doesn't have the salt values (which is what makes them
secret).  I don't see any other way to interpret the statement above.

I think the real problem here is that you're trying to add an additional
constraint to salt-and-hash password-storing protocols ("salt must be kept
secret") in the belief that in return you get a significant new security
benefit ("secret salt makes brute-forcing password hashes harder").  I'm
asking you to analyze the probability of an attack where that benefit
applies.  What threat model incorporates an attack where that's true?  And
how significant is that branch of the attack tree?

Frankly, if you have a threat model where salt-and-hash doesn't suffice,
you'd be much, much better off switching to a stronger scheme.  There are
various protocols that use zero-knowledge proofs of identity, for example,
like SRP (RFC 2945) or PAK-RY [1].  Trying to strengthen salt-and-hash is
probably not a great use of resources.

> Couldn't agree more and one benefit of using salt is that it 
> creates more random passwords.

That's dangerously imprecise (some might say flat-out wrong).  Salt doesn't
affect the randomness or entropy of passwords at all.  It adds entropy to
the password hash function (trivially, a file of salted password hashes of
the same password is less compressable than a similar file with unsalted
hashes).

> Maybe a better way to phrase it is to use 1 asymmetric key for the 
> encryption and the other for the decryption.  Neither would 
> be public.

Why asymmetric encryption at all?  That just means two keys, either of which
would help the attacker.  (With the encryption key, the attacker could
encrypt his dictionary; with the decryption key, the attacker could decrypt
the password hash list.)



1. http://cm.bell-labs.com/who/philmac/pak_view/pak_view.html

-- 
Michael Wojcik
Principal Software Systems Developer, Micro Focus