Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email email@example.com
RE: Values to use for a salt?
From: Kenneth Buchanan (K.BuchananKastenchase.com)
Date: Fri Dec 19 2003 - 14:16:42 CST
> 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
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
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).
From: Brian Hatch [mailto:briifokr.org]
Sent: Friday, December 19, 2003 2:39 PM
To: Scott Cleven-Mulcahy
Cc: Michael.Wojcikmicrofocus.com; secprogsecurityfocus.com
Subject: Re: Values to use for a salt?
> Most systems that I'm aware of use the same key, I presume for speed
Or because they're written by people who don't know what
> 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
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
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