The Case of the Missing Passwords

The Case of the Missing Passwords

Not so very long ago, we heard about a certain Linux administrator who looked in the /etc/passwd file, saw that there were no passwords, and asked, "Can we just delete these entries where there are no passwords?".

Hmmmmm. . .

What's wrong with this picture?

Well, the fact is, that actual passwords have never been stored in the passwd file. At one time though, when Linux was in its infancy, you could have opened the passwd file and seen a string of gibberish in the password field. This gibberish would have been the encrypted--or more accurately--the "hashed" version of the actual password. (The difference is that an encrypted password can be unencrypted back to its original form, but a hashed password can't be unhashed.) When users create a password for themselves, the system will choose a random "salt" value to perform the hash. If two users choose the same password, the hashes will be different, since the system will use a different "salt" value for each. Since the system knows the salt values for each password, it can tell when a user enters the proper password. There were a few weaknesses to this approach, though.

First, the /etc/passwd file needs to be world-readable, so that non-root users will be able to access it when logging on to the system. If you look at the permissions settings, you'll see that it's only writable by the user, who is "root" in this case. But, since the "passwd" utility has the SUID bit set, this file is effectively world-writable, as well. That's so that non-root users can set passwords for themselves. Keeping password hashes in a file that's both readable and writable by the world just makes things too easy for intruders who would either want to run a password crack program, or who would want to surreptitiously add root accounts for themselves.

The other problem with this approach is that it uses a rather outdated, weak hash algorithm. The "3DES" algorithm is relatively easy to crack with modern computers, and it limits passwords to a length of only eight characters. (Having to use shorter passwords also makes the system more susceptible to "brute force" attacks.)

Nowadays, just about every Linux distro you come across will use not only the /etc/passwd file, but also the /etc/shadow file. This approach solves both of the above problems.

Unlike the passwd file, the shadow file is only readable and writable by root. So, storing the password hash in shadow, instead of in passwd, makes an intruder's job somewhat harder. (When a user logs on to the system or creates a password for himself, he'll still need non-root access to the passwd file. However, the Linux system, acting as a proxy for the root user, will access the shadow file.)

Also, by using the shadow file method, the system is no longer limited to using the 3DES hash algorithm. Most systems now use the MD5 algorithm by default. MD5 makes for a stronger hash, and it doesn't limit passwords to any certain length. So, you have both an algorithm that's harder to crack, and a longer password that's less likely to be cracked by brute-force.

Here's another benefit of using the shadow file. . .

Security experts recommend that users change their passwords on a regular basis. Most users won't do that on their own, but you can force them to by setting expiration dates. The shadow file contains a field to hold expiration date information, but the passwd file doesn't. (There are quite of few options for this, and you'd use the "chage" utility to do it. Enter "man chage" at the command-line for all the details.)

The "pwconv" utility is available for converting non-shadowed user accounts. But, since the shadow system is turned on by default on probably all distros of Linux, there's a good chance that you'll never use it.