 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
UserID
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:
W1wEdEKQNtJbA
^ ^
| |
| encrypted password
salt
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, pwexp.pl, 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: http://www.sysadminmag.com.)
pwexp.pl 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, pwexp2.pl, 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 pwexp2.pl
command results in the output shown below:
# ./pwexp2.pl
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.
| 
