Home
| Calendar
| Mail Lists
| List Archives
| Desktop SIG
| Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings Linux Cafe | Meeting Notes | Linux Links | Bling | About BLU |
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 | |
We also thank MIT for the use of their facilities. |