RE: Values to use for a salt?

>	SALTpassword	<== precompute hash of SALT, then do all
>			    possible passwords.

Without intending to dispute your good advice, the above statement is only
true if the size of the salt is >= the size of the input to the hash
compression function.

In SHA-1 that's 20 bytes, I believe.  So if you use a 64-bit salt, then the
appending order of password and salt is irrelevant for passwords up to 12
bytes long.

But that's just being picky.  You should still put the salt after the
password, particularly since those 12 password bytes don't go very far if
your password happens to be a Unicode string.  And the MD5 compression
function uses a 16-byte input, leaving you with only 8 bytes of password
space before spilling over into the next hash iteration.

> I still have no idea what you really mean here.

I think he meant 'more random hashes', which isn't really true.  The *only*
purpose of a salt, as has been mentioned repeatedly in this thread, is to
provide resistance to dictionary attacks by making precomputation
infeasible.  For this it must be unpredictable by the attacker.  Once you
get passed this then you are either  misusing salts, or you are calling
something a salt that really isn't (ie. MAC key != Salt, which is a
confusion that appeared to be popping up in other messages).


-----Original Message-----
From: Brian Hatch [mailto:[email protected]]
Sent: Friday, December 19, 2003 2:39 PM
To: Scott Cleven-Mulcahy
Cc: [email protected]; [email protected]
Subject: Re: Values to use for a salt?




> Most systems that I'm aware of use the same key, I presume for speed 
> reasons.

Or because they're written by people who don't know what
they're doing.

> Since the key is added to the password before hashing it seems to 
> me that it only serves to make the password more random.  So "MyPassword" 
> becomes "1234MyPassword".  This has only made the password more random and

> generates the same hash code for every password that is "MyPassword".

If you're going to salt, then you need to put the salt at the *END*
of the password.  Otherwise the cracker can precompute the salt in
the hashing routine, and there's no speed difference between a salted
password and an unsalted password.

	SALTpassword	<== precompute hash of SALT, then do all
			    possible passwords.
	
	passwordSALT	<== compute each password followed by
			    salt - no precomputation possible.

Always put the 'known' bit last.  (Here assuming the salt is
either known (stored in the resulting hash) or knowable (it's
stored somewhere inside the application or application logic
and thus is essentially knowable anyway.)

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

I still have no idea what you really mean here.

password+salt is not a password, it's a password+salt.
It's the 'thing to be hashed' but it's not the password
any more.



--
Brian Hatch                  Turning off setuid bits
   Systems and                of important unix tools
   Security Engineer          is like poking out an
http://www.ifokr.org/bri/     eye to prevent misuse.
                              -- Nick Esborn.
Every message PGP signed