Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Blog | Linux Links | Bling | About BLU

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Discuss] salt question



Eric Chadbourne wrote:
> And don't quite understand this line: "Salts are normally stored
> along with the hashes. They are not secret."

When you authenticate yourself, your supplied pass phrase (and perhaps
login name) are run through a hash or encryption algorithm. The output
of the algorithm is compared with the stored hash or cipher text. If the
two match then authentication is approved; if not then authentication is
denied.

For a given string such as a pass phrase, different salts will produce
different hashes or cipher text. The salt used for a given account must
be known to the algorithm for secure authentication to function. This
isn't anything new nor is it inherently insecure. The oldest practical
example that I can think of is traditional UNIX DES passwords. The DES
salt for each user's password is derived from the first two characters
of the user's login name. Later implementations use the entire login 
name as the salt.

Do you see how with the DES password system each account has a more or
less unique salt? Each unique salt requires a unique rainbow table
since, as noted, different salts for the same plain text generate
different output. Reasonably secure systems generate unique salts for
each account so that a single rainbow table can't be used to compromise
the entire account list. Since these salts must be known to the
authentication system for them to be useful it makes sense to store them
with the hashed or encrypted password information.

-- 
Rich P.



BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org