Encrypting passwords is an interesting subject, since you don't need to ever decrypt them, just check to see if the password you got is the password that the user entered.

Under unix this is done with the crypt(3) function call, and passwords are usually stored either covered by a one way hash using DES, SHA-1 or MD5.

A problem with just hashing passwords is that people can take a dictionary of commonly used passwords and hash them all, then when they get a password file1? they can compare the passwords in the password file against their list of hashes to find common passwords. To combat this people add "salt" to their password, ie: they add a random prefix to the password when they encrypt it, and then check to see if it's the same.

For example, if we're using the password samsam we might add the salt of q6. So we hash q6samsam and get LHtEJQdGJW2. Then we put the salt onto the beginning of this string to give us q6LHtEJQdGJW2, and this would go into the password file.

When someone logs in we want to check to see if the password they presented is the same as in the password file, so we take the password hash in the password file q6LHtEJQdGJW2, remove the first two letters (q6), add them to the beginning of password that the user entered (samsam), and hash q6samsam and get LHtEJQdGJW2, we compare this against the rest of the password hash, see that it's a match, and then let !SamJenson? login.

There are 4096 different possible salts under Unix, which means that while you could generate a huge password hash list, it would have to be 4096 times larger than a normal one. Nowadays, though, this is hardly a hindrance anymore. MicrosoftWindows doesn't use salts for its passwords and is more vulnerable to this kind of attack.

1?: Much harder to do now that everyone has shadow files.