8/31/2009 -- In a perfect world, there wouldn't be such a file as /etc/shadow; it carries too much of a security risk if it falls into the wrong hands. In the real world, however, authentication information needs to be stored somewhere -- and that responsibility falls to this file.

The danger? This file contains an encrypted version of the passwords for users who are defined in the /etc/passwd file.

In early versions of Unix/Linux, all the user account and password information was stored directly in passwd, but only root could write to it. This offered sufficient security because the password was encrypted in this file as a hash value that was then compared against the new hash created when a user typed in their password at a prompt. The problem was that the permissions allowed more than root to read the file, and everyone became root during the time needed to change their password.

To make things more secure, the hashed password values were moved from the second field of passwd to shadow, and the permissions for each file reflected additional security measures:

When shadow is in use, only an "x" appears in the second field of passwd now (when shadow is not in use, the encrypted password hash appears in that field). While the values are now more protected, if the file were to fall into the wrong hands -- via a misplaced backup, privilege escalation, etc. -- it becomes possible for someone to wreak havoc.

Like passwd, the shadow file is colon (:) delemited, and there are nine fields. Here's an example:

edulaney:$1$AAAni/yN$uESHbzUpy9Cgfoo1Bf0tS0:13800:0:99999:7:::

The value of the fields are as follows:

1. The username. This corresponds to the first field in the passwd file and is the only field where the two files match.
   
   
2. A hashed copy of the password. An asterisk (*) or exclamation mark (!) denotes an account with no password and is common for accounts used by the system itself. Within this field, there is the possiblity for the first three characters to be a dollar sign ($), a number and another dollar sign. For example:

   $1$AAAni/yN$uESHbzUpy9Cgfoo1Bf0tS0

   The "1" between the dollar signs in the second field indicates that MD5 encryption has been used here. A pluggable authentication module (PAM) is needed to perform the actual MD5 encryption. If the number between the dollar signs is 2, then Blowfish was used.
   
   
3. The date of the last password change. This is depicted as the number of days since Jan. 1, 1970.
   
   
4. The number of days that must pass before the next password change is allowed. A 0 here means the user can change their password when they want to.
   
   
5. The number of days after the last password change before another password change is required.
   
   
6. The number of days before the password expiration to start giving a warning to the user. The most typical value is 7.
   
   
7. The number of days that are allowed between expiration and deactivation.
   
   
8. The expiration date, again expressed as a number of days since Jan. 1, 1970.
   
   
9. A "special" flag that is reserved for future use.

First, you can check a user's password-expiration information with the command:

chage -l edulaney

This command displays expiration information, including when the last password change was, when it expires, when it goes inactive and how often the password must be changed. In the entry shown, "never" would be returned for when the password expires, when the password goes inactive, and when the account expires. The -l option is the only one that can be run with chage by all users and not just the root user (so every user can see when their account expires).

To force the user to change a password in 90 days, use the following command:

chage -M 90 edulaney

This will change the fifth field in the example from 99999 to 90.

There are programs, such as John the Ripper, which exist to simplify the cracking of this field. Given the values in a shadow file, it will begin guessing entries and encrypting them to find a match. It's amazing how quickly values can be found just by using entries in a common word file (like a dictionary).

As with most security-related issues, the best defense is a good offense. Keep all copies of the shadow file -- whether they're on backup tape or other media -- secure and out of the hands of all but those who absolutely must have access to it.