logo       

Re: Values to use for a salt?: msg#00035

security.programming

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

Attachment: pgpo3AK4zCjyU.pgp
Description: PGP signature

<Prev in Thread] Current Thread [Next in Thread>
Google Custom Search

News | FAQ | advertise