Stored passwords, eggs and bread dough?

All three of these share the need for one thing: salt. So what is a password salt and why do we need them?

In the early days of the UNIX timesharing system the file containing the users’ passwords was readable by all users (that began in version 6, in the mid 1970’s). The file had the following fields, separated by colons:

name (login name, contains no upper case) The username.
encrypted password The part that Is important for us.
numerical user ID A number identifying the user to the system. Throughout the system – including the information about who owns a particular file – the ID is used instead of the actual user name.
GCOS job number and box number This became just the user’s “real name”.
initial working directory The user’s “home directory”.
program to use as Shell The program the user used as an interface. The system was text-based and there have been multiple choices over the years.

Why was the password file readable by everyone? If you look at the description above, you’ll see that the owners of files on the system are identified by numbers (called the uid in the kernel, and “numerical user ID in the password file). It would be pretty unfriendly to show files as owned by user 129, so the program to list files looked up 129 in this file and would use the actual username of the user.

This presented a problem, though: everyone could see the encrypted passwords. (Which weren’t exactly “encrypted” they were hashed — mathematically manipulated in such a way that the initial data cannot be recovered from the result . That meant if Alice and Bob each chose “eraser” for their passwords, they’d both see the same string in the password file and so they’d know each other’s passwords. Not good. The creators of UNIX came up with a solution to add two characters representing random bits – the salt – to a user’s password before encrypting it. So if the password were ‘eraser’ and the salt ‘xZ’ the password program would encrypt ‘eraserxZ’. The system would store the salt along with encrypted password so ‘xZTvssAJ.n6pU’ would be stored in the file.  This also made the passwords harder to discover: if a bad guy made a list of all encrypted passwords, without the salt he could just look in password files and extract user passwords. That would not have been practical in those days, but a list of short, simple passwords surely was – the Morris and Thompson paper discusses the details.

Now fast-forward to the present.  Websites often store passwords as hashes (as do most computer systems). They tend to use algorithms such as MD5 or one of the SHA algorithms.  This means if a user has the same password on two or more sites, and they use the same hash algorithm, and they are not salted, the password hash will be the same on all the systems. That means if your password hash on site X is discovered, and you use the same password on Y, they will have the same hash, making it clear to attackers you are using the same password. Had the passwords been salted, the attackers wouldn’t have known.

(Strict UNIX historians will note that I am compressing a bit of history here. Check out “Password Security: A Case History”by Robert Morris and Ken Thompson and “ UNIX Password Security – Ten Years Later” by David Feldmeier and Phillip Karn.)

Check out course 468, System and Network Security, for more info on changing passwords and about hashes and “salt”.

John McDermott

Type to search blog.learningtree.com

Do you mean "" ?

Sorry, no results were found for your query.

Please check your spelling and try your search again.