Linux Shadow Password HOWTO: Why shadow your passwd file?

2. Why shadow your passwd file?

By default, most current Linux distributions do not contain the Shadow Suite installed. This includes Slackware 2.3, Slackware 3.0, and other popular distributions.

If you installed a distribution from a CD-ROM, you may find that, even though the distribution did not have the Shadow Suite installed, the files you need to install the Shadow Suite are also on the CD-ROM. This is especially true if you have a Sunsite Mirror CD-ROM.

The needed files may also be obtained via anonymous FTP or through the World Wide Web.

On a Linux system without the Shadow Suite installed, user information including the passwords are stored in the /etc/passwd file. The password is stored in an encrypted format. If you ask a cryptography expert; however, he or she will tell you that the password is actually in an encoded rather than encrypted format because when using crypt(3), the text is set to null and the password is the key. Therefore, from here on, I will use the term encoded in this document.

The algorithm used to encode the password field is technically referred to as a one way hash function. This is an algorithm that is easy to compute in one direction, but very difficult to calculate in the reverse direction. More about the actual algroithim used can be found in the section on the crypt(3) algorithm or your crypt(3) manual page.

When a user picks a password, it is encoded with a randomly generated value called the salt. This means that any particular password, could be stored in 4096 different ways. The salt value is then stored with the encoded password.

When a user logs in and supplies a password, the salt is first retrieved from the stored encoded password. Then the supplied password is encoded with the salt value, and then compared with the encoded password. If there is a match, then the user is authenticated.

It is computationally difficult (but not impossible) to take a randomly encoded password and recover the original password. However, on any system with more than just a few users, at least some of the passwords will be common words (or simple variations of common words).

But the system cracker knows all this, and will simply encrypt a dictionary of words and common passwords using the all possible 4096 salt values. Then they will compare the encoded passwords in the /etc/passwd file with their database. Once he/she has found a match, they have the password for another account. This is referred to as a dictionary attack, and is one of the most common methods for gaining or expanding unauthorized access to a system.

If you think about it, an 8 character password encodes to 4096-13 character strings. So a dictionary of say 400,000 common words, names, passwords, and simple variations would easily fit on a 4GB hard drive. The attacker need only sort them, and then check for matches. Since a 4GB hard drive can be had for under $1000.00, this is well within the means of most system crackers.

Even without lots of drive space, utilities like crack(1) can usually break at least a couple of passwords on a system with enough users (assuming the users of the system are allowed to pick their own passwords).

The /etc/password file also contains information like user ID's and group ID's that are used by many system programs. Therefore, the passwd file must remain world readable. If you were to change the /etc/passwd file so that everyone can't read it, the first thing that you would notice is that the ls -l command now displays user ID's instead of names!

The Shadow Suite solves the problem by relocating the passwords to another file (usually /etc/shadow). The shadow file is set so that it cannot be read by just anyone. Only root will be able to read and write to the /etc/shadow file. Some programs (like xlock) require that the group shadow be allowed to read the /etc/shadow file. This is actually a good idea as programs that only need to read and verify passwords can be run SGID shadow rather than SUID root.

By moving the passwords to the /etc/shadow file, we are effectively keeping the attacker from having access to the encoded passwords with which to perform a dictionary attack.

Additionally, the Shadow Suite adds lots of other nice features:

A configuration file to set login defaults (/etc/login.defs)
Utilities for adding, modifying, and deleting user accounts
Password aging and expiration
Account expiration and locking
Shadowed group passwords (optional)
Double length passwords (16 character passwords)
Better control over user's password selection
Dial-up passwords
Secondary authentication programs

Installing the Shadow Suite helps to contribute toward a more secure system, but there are many other things that can also be done to improve the security of a Linux system, and there will eventually be a series of Linux Security HOWTO's that will discuss other security measures and related issues.

For current information on other Linux security issues, including warnings on known vulnerabilities see the Linux Security home page.

2.1 Format of the /etc/passwd file

A non-shadowed /etc/passwd file has the following format:


username:passwd:UID:GID:full_name:directory:shell

Where:

username: The user (login) name
passwd: The encoded passwd
UID: Numerical user ID
GID: Numerical default group ID
full_name: The user's full name - Actually this field is called the GECOS (General Electric Comprehensive Operating System) field and can store information other than just the full name.
directory: User's home directory
shell: User's login shell

For example:


username:Npge08pfz4wuk:503:100:Full Name:/home/username:/bin/sh

Where Np is the salt and ge08pfz4wuk is the encoded password. The encoded salt/password could just as easily have been kbeMVnZM0oL7I and the two are exactly the same password. There are 4096 possible encodings for the same password. (The example password in this case is 'password', a really bad password).

Once the shadow suite is installed, the passwd file would instead contain:


username:x:503:100:Full Name:/home/username:/bin/sh

The x in the second field in this case is now just a place holder. The format of the /etc/passwd file really didn't change, it just no longer contains the encoded password. This means that any program that reads the /etc/passwd file but does not actually need to verify passwords will still operate correctly.

The passwords are now relocated to the shadow file (usually /etc/shadow file).

2.2 Format of the shadow file

The /etc/shadow file contains the following information:


username:passwd:last:may:must:warn:expire:disable:reserved

Where:

username: The User Name
passwd: The Encoded password
last: Days since Jan 1, 1970 that password was last changed
may: Days before password may be changed
must: Days after which password must be changed
warn: Days before password is to expire that user is warned
expire: Days after password expires that account is disabled
disable: Days since Jan 1, 1970 that account is disabled
reserved: A reserved field

The previous example might then be:


username:Npge08pfz4wuk:9479:0:10000::::

2.3 Review of crypt(3).

>From the crypt(3) manual page:

"crypt is the password encryption function. It is based on the Data Encryption Standard algorithm with variations intended (among other things) to discourage use of hardware implementations of a key search.

The key is a user's typed password.

The salt is a two-character string chosen from the set a-zA-Z0-9./. This string is used to perturb the algorithm in one of 4096 different ways.

By taking the lowest 7 bit of each character of the key, a 56-bit key is obtained. This 56-bit key is used to encrypt repeatedly a constant string (usually a string consisting of all zeros). The returned value points to the encrypted password, a series of 13 printable ASCII characters (the first two characters represent the salt itself). The return value points to static data whose content is overwritten by each call.

Warning: The key space consists of 2**56 equal 7.2e16 possible values. Exhaustive searches of this key space are possible using massively parallel computers. Software, such as crack(1), is available which will search the portion of this key space that is generally used by humans for passwords. Hence, password selection should, at minimum, avoid common words and names. The use of a passwd(1) program that checks for crackable passwords during the selection process is recommended.

The DES algorithm itself has a few quirks which make the use of the crypt(3) interface a very poor choice for anything other than password authentication. If you are planning on using the crypt(3) interface for a cryptography project, don't do it: get a good book on encryption and one of the widely available DES libraries."

If you are looking for a good book on encryption, I recommend:

        "Applied Cryptography: Protocols, Algorithms, and Source Code in C"
        by Bruce Schneier <schneier@chinet.com>
        ISBN: 0-471-59756-2