Cover V10, I10

Figure 1
Figure 2
Figure 3
Table 1
Table 2


Revisiting UNIX Password Controls -- Part 1

Chris Hare

This article is based on work first appearing in the premiere issue of Sys Admin magazine, May/June 1992, "Where Did that Core File Come From?" and "How UNIX Password Controls Work", both by Chris Hare. --editor.

One problem with writing articles about security-related issues is the fear that someone will use what you have written to attack a system. An advantage is that the more systems administrators know about how the tools work, the more able they are to protect their systems.

This article discusses UNIX password controls including the encryption systems used, password rules and validation, password shadows, and aging. The discussion describes how the system works and presents some methods that attackers use to circumvent it.

Ensuring that users select good passwords is the administrator's primary mechanism for controlling access to the machine. This is the most common breakpoint in any computing environment where the user sets the password. It is ironic that most password systems leave password strength in the hands of the user. The opposite scenario, in which the user has no control over password assignment, often results in the user writing the password down somewhere, immediately snapping the security chain.

Password Storage

Passwords can be stored in a number of places depending upon the UNIX variant and how the system is configured. Table 1 lists the more common systems and places where passwords can be stored.

The "shadow file" was created to address the problem associated with the readability of the encrypted passwords. Because the encrypted passwords were exposed to all system users, and the algorithm to encrypt the password is well understood, it was possible to build highly effective password guessing programs, called password crackers. Consequently, the shadow file was established to store the encrypted passwords and enforce a higher degree of control over which users or system services could see them.

The format of the password file is consistent across UNIX implementations, but the same is not true for the shadow file, as covered later in this article. Each UNIX user must have a password file entry. However, client/server applications that do not provide the user with UNIX-level access do not generally require the user to have a UNIX-level account, because the application itself performs the user authentication and management. Some applications, however, do use the UNIX-level authentication methods. This is specific to the application and outside the scope of this discussion.

Each password entry in /etc/passwd has the format:

userid:password:UID:GID:Comment:Home directory:shell
and looks like:

chare:x:500:500:Chris Hare:/home/chare:/bin/bash
^     ^ ^   ^   ^          ^           ^
|     | |   |   |          |           |
|     | |   |   |          |           login shell
|     | |   |   |          home directory
|     | |   |   Comment or GECOS
|     | |   Group Number (GID)
|     | User Number (UID)
|     Password or placeholder

The UserID field contains the user's actual account name. The password field will contain either the actual encrypted password, or a placeholder (such as in this example). The placeholder indicates that a shadow file is used. The User Number, or UID, is a unique identifier used by the system to distinguish between users. The Group Number, (or GID), is used to determine what groups the user belongs to and maps to an entry in the /etc/group file.

The comment or GECOS field can contain any text information to identify the user. This typically includes the user's name and other information, such as phone number or department name. The home directory specifies where the user is placed when he first logs into the system, and the login shell determines what command interpreter is used.

Password Encryption Techniques

The real issue at hand is how the UNIX password mechanism is implemented. At one time, the passwords were stored in an unencrypted format and only the administrator and system software had access to the file. The problem arose when the password file, /etc/passwd, was being edited. Because most editors create a temporary file for editing purposes, during editing the file would be world-readable, exposing the passwords for all of the accounts. As a result, a method of encrypting the passwords using a one-way encryption algorithm and storing the encrypted values was provided. However, the security of the system is only as good as the encryption method chosen.

When a user logs into a UNIX system, the getty program prompts for the username and executes the login program. The login program prompts for the password, but does not decrypt it. In fact, the /bin/login program encrypts the password supplied by the user, then compares the newly encrypted value to the one stored in /etc/passwd. If they match, then the password supplied the correct value.

The most commonly used encryption method is the enhanced Data Encryption Standard (DES) system. DES itself is a symmetric key system, meaning the same key is used for encryption and decryption. If the algorithm had not been enhanced, two users with the same password would have had exactly the same encrypted value. This problem still exists with the enhanced system, if the password field from one user is copied into the password field of another user. However, with the enhanced DES method, two users can have the same password but the encrypted values will be different. This is explained in the next section.

Understanding UNIX DES Password Encryption

The UNIX encryption method for password encryption is accessed via the system call crypt(3). Because of U.S. export control, the crypt routines may not be available on your system.

The actual value stored in /etc/passwd results from using the user's password to encrypt a 64-bit block of zeroes via the crypt(3) call. The "clear text" is the user's password, which is the key to the operation. The resulting "cipher text" is the encrypted password. Clear text (also known as plain text) is the original unencrypted message. Cipher text is the message after encryption.

The crypt(3) algorithm is based upon the Data Encryption Standard (DES) developed by the National Institute of Standards and Technology (NIST). In normal operation, according to the DES, a 56-bit key, such as eight 7-bit characters, is used to encrypt the original text, commonly called "clear text". This clear text is typically 64 bits in length, which is why UNIX only recognizes the first 8 characters of the password provided by the user. The resulting cipher text cannot easily be decrypted without knowledge of the original key.

The UNIX crypt(3) call uses a modified version of this method by stating that the clear text be encrypted in a block of zeroes. Encrypting the resulting cipher text again with a user's password as the key further complicates the process. This process is performed 25 times, and, when it is complete, the resulting 64 bits are split into 11 printable characters and saved in the password file.

Although source for crypt(3) can be obtained from many vendors (even though the distribution of this is limited outside the United States), there is no known method for translating the cipher text or encrypted value back to its original clear text.

Robert Morris, Sr., and Ken Thompson, who originally implemented the UNIX crypt(3) technology, were concerned that with the advent of hardware DES chips the security of the UNIX system could easily be bypassed. By using a "grain of salt", they managed to disarm this threat.

The "grain of salt" is a 12-bit number used to modify the result of the DES function. The value of this number ranges from 0 to 4095. The result is that each possible password could be represented in any one of 4096 ways in the password file. Multiple users on the same machine could be using the same password and no one, including the system manager, would be the wiser.

When a user runs the /bin/passwd program to establish a new password, the /bin/passwd program picks a salt value based upon the time of day, which is then used to modify the user's password.

To prevent problems in the unlikely case that the user's next login generates a different salt value, UNIX stores the salt in /etc/passwd as well. In fact, this value makes up the first two characters of the encrypted password. This mechanism means the password can be encrypted again and a match found.

For example, the encrypted password value:

^ ^
| |
| encrypted password
is composed of the salt and the actual 11-character encrypted password. From our example, the user enters his password during the login process and the salt, W1, is added during the encryption process. Once the password entered by the user is encrypted, it is compared with the encrypted value stored in the appropriate file (remember it could be in a shadow file). If the two values match, the user is granted access. Entering the password does not decrypt the value stored on the system, as is commonly believed.

Understanding MD5 Password Encryption

Linux is the first UNIX-based operating system to introduce Message Digest 5, or MD5, as a method of password encryption for the login process. This is accomplished using the Pluggable Authentication Module (PAM) system to enhance or replace the default DES encryption process. This is only one part of the PAM capabilities. Before looking at the Message Digest 5 algorithm, a brief look at PAM is warranted.

It is the goal of the PAM projects to remove the authentication components from privilege-granting software. This allows the authentication module of choice to be determined by the systems administrator at runtime, and not by the software vendor. In the context of this discussion, the authentication modules could be the standard UNIX DES encryption, MD5 encryption, Kerberos, or any other such method. The PAM environment itself is outside the scope of this discussion. (See "PAM -- Pluggable Authentication Modules" by Kurt Seifried, Sys Admin magazine, September 2000.)

The system.auth file in the /etc/pam.d directory defines the authentication methods used. A sample is shown in Figure 1. The Module Type field is used for updating the authentication tokens, or passwords, associated with the user. There is typically one PAM module for each form of authentication. The Control Flag defines how the PAM library will react to the success or failure of the authentication. The control flag "sufficient" as defined here means the success of the PAM library constitutes a successful authentication or update.

There is an important distinction to be considered with PAM. Because it is a pluggable module approach, there can be more than one layer of authentication used to gain access to a component, application, or the operating system itself.

The module path is the location of the pluggable modules. The arguments for the pluggable module are specific to each given module and define how that module will operate.

In this example, the arguments md5 and shadow are important. It is these arguments that instruct PAM to use MD5 passwords and establish the shadow password file.

The MD5 algorithm is documented in the Internet Engineering Task Force Request for Comments (RFC) 1321. Ron Rivest of RSA Data Security originally developed it. The status of the RFC is informational, meaning it does not document an Internet Standard. The Message Digest algorithm is used to generate a fingerprint, or message digest, of the password. Actually, MD5 has many more uses and is commonly used in digital signatures. MD5 is based upon the Message Digest 4 or MD4 algorithm. While MD4 is very fast, it may be possible to launch a successful attack against it. While MD5 is a little slower to provide a more secure encryption function, it is designed to be very fast on current computing platforms. Users will not notice the speed difference between using the DES or MD5 password encryption methods.

The MD5 implementation of the password mechanism works in a similar fashion to the DES implementation. A salt is used to vary the encryption process. The password in the Linux implementation is shown in Figure 2.

The magic string used in the MD5 implementation identifies the password as an MD5 encrypted password, so the PAM module knows to use the correct encryption process when comparing the user-supplied and stored values. The salt, like the DES implementation, is used to vary the MD5 encryption process. This prevents two users, both using the same password, from having the same encrypted value.

Unlike the DES implementation, however, the salt in the MD5 process can be up to eight characters in length. The "$" is used between the salt and the password to delineate where one ends and the next begins, given the variable length of the salt. The MD5 password can be 13 to 24 characters in length.

Password Controls

There are three primary controls available to the systems administrator, security officer, and systems auditor -- password shadows, aging, and quality. This section introduces password shadows and aging for the most common systems.

Many versions of UNIX provide password-aging features to control when users can change their passwords. Password aging is controlled by means of a value inserted into the password file after the encrypted password. This value defines the minimum period of time that must pass before a user can change a password and the maximum period of time that can elapse before the password has expired. Figure 3 provides a representation of the concept.

If the password shadow file is not used, password aging control information is stored with the encrypted password as a series of printable characters. Password aging is controlled differently when a shadow file is used, and is presented later in the article.

In the traditional UNIX scenario, the password aging controls are included after the password, preceded by a comma. The characters represent:

  • The maximum number of weeks the password is valid;
  • The minimum number of weeks that must elapse before the user can change the password again;
  • When the password was most recently changed.

Table 2 lists the character representations and their values.

The aging control mechanisms recognize two special conditions: one that forces the user to change the password on next login, and one that prevents the user from being able to change it.

To force a user to change a password, as in the case of a new user, the user's password field is modified to include a comma followed by two periods representing the maximum and minimum time frames. These values force the user to change the password at the next login. When the password has been changed, the "force" control information is removed from the password entry.

The second special case prohibits a user from being able to change a password. This condition is established by setting the maximum value to be less than the minimum value. In this case, the user is informed that the password cannot be changed when they next attempt to log in.

Some of the newer, more secure versions of UNIX use the term "password lifetime". This denotes a grace period after the maximum time period has elapsed during which the user may still log in using the expired password. Once the lifetime has been reached, the account will be disabled. The password lifetime mechanism doesn't prevent a user from changing a password and then changing it back to the old one later. Only a few UNIX system versions keep track of the passwords a user has used. The actual process of implementing password aging is version-dependent. To implement it on your system, consult your system documentation.

The program in Listing 1,, provides advance notice of password expiration dates so that users can be prepared for the day when the system demands a new password. Note, however, that this version of the program is for standard System V UNIX, where a shadow password file is not used. (Listings for this article are available from the Sys Admin Web site: addresses the aging mechanism that was implemented in versions of UNIX up to System V Release 3.2. At this level, some variations took place in the interest of increasing system security. The result was several different methods for controlling shadow files. The BSD and AT&T System V Release 4 derivatives moved to use /etc/shadow, while other systems including SCO UNIX from the Santa Cruz Operation and HP-UX from Hewlett-Packard implemented the Trusted Computing Base. Interestingly enough, the SCO UNIX implementation can use /etc/passwd, /etc/shadow, or the Trusted Computing Base depending upon the security level at which the system is operating. IBM's AIX implementation uses yet another mechanism for the storing shadow passwords and aging information.

The program in Listing 2,, prints password change and aging information for systems using the /etc/shadow file. The program must be run as root, since the /etc/shadow file is not readable by a non-root user. Executing the command results in the output shown below:

# ./
Last Password Change
Username         Last Changed on  Can Change      Must Change
root             Wed Mar 28 2001  Now             Never
chare            Wed Mar 28 2001  Now             Mon Sep 24 2001
luciano          Thu Mar 29 2001  Now             Tue Sep 25 2001
sipes            Thu Mar 29 2001  Now             Tue Sep 25 2001
rsivanan         Thu Mar 29 2001  Now             Tue Sep 25 2001
seal             Fri Mar 30 2001  Now             Wed Sep 26 2001
This article discussed how the UNIX password system works and described password encryption using both the UNIX DES and MD5 encryption methods. Password aging, or having the system expire the passwords to force the users to periodically change them was also covered, and two utilities were presented to print the password aging parameters. The second half of this article will cover the shadow password file and password quality.

Chris Hare has more than 14 years of computing industry experience including application design, quality assurance, systems administration/engineering, network analysis, and security consulting, operations, and architecture. He is the co-author of New Riders Publishing's Inside UNIX, Internet Firewalls and Network Security, Building an Internet Server with Linux, and The Internet Security Professional Reference. Chris has also written a number of articles for Sys Admin magazine since its inception in 1992 and has written for Recruiting and Supervision Today magazine. Chris is now writing for Auerbach's Data Security Management. Chris teaches information security at Algonquin College (Ottawa, Canada) and is currently employed with Nortel Networks as an Information Security and Control Consultant in Ottawa, Canada.