UNIX Password Controls -- Part 2
This article is based on work first appearing in the premiere
issue of Sys Admin magazine, May/June 1992, "How UNIX
Password Controls Work", by Chris Hare. --editor
The first part of this two-part series (Sys Admin, October
2001) discussed the encryption methods used in protecting the passwords
on a UNIX system. It introduced the concept of password aging and
presented several utilities for reviewing the password aging applied
to each user account. Part 2 presents using a shadow file to provide
further protection for the encrypted passwords, password quality,
and the validity of password cracking tools.
As discussed previously, there are three primary versions of shadow
files in use. While the formats of these files are different, their
goal is the same: to protect the actual encrypted passwords and
provide additional controls, including password aging.
The /etc/shadow file is the first of the three common formats.
This file format is illustrated in Figure 1. For each user in the
/etc/passwd file, there must be a corresponding /etc/shadow
entry. The encrypted password is not immediately identifiable, but
a DES encrypted password is typically 13 characters -- a 2-character
salt and an 11-character password. The example shown in Figure 1
is an MD5 encrypted password.
The third field identifies the days since the epoch (January 1,
1970) that the user last changed his password. The fourth field
is the number of days the user must wait before he can change his
password. The default in most installations is zero, meaning he
can change his password at any time.
The fifth field specifies the number of days the password is valid
before the user must change it. The password aging routines add
this number of days to the date the password changed to determine
whether the password must be changed. Password aging has little
value if the user is not notified before the password expiration
period is reached. The sixth field is the number of days before
password expiration that the user is notified to change his password.
The seventh field is the grace period. During this time, the user
can still login, but before his shell is executed, he must change
his password. Failing to make the password change within this time
period means the account is disabled. When the account is disabled,
it cannot be used to access the system. The eighth field is the
number of days the account has been disabled, represented as the
number of days since January 1, 1970. The final field is reserved
and is not used in current implementations of the shadow file.
The /tcb/files structure is driven from the C2 Security
packages created by SecureWare, and implemented in Hewlett-Packard's
HP-UX and the Santa Cruz Operation's SCO Unix. This is an integral
part of the Trusted Computing Base, which is why the directory structure
starts with /tcb. There is a set of complex files in this
directory to provide for the implementation of the C2 security features.
Most of these files are not applicable to this discussion. However,
the shadow files are implemented in the directory path /tcb/files/auth.
Within this directory are more directories named by letter of
the alphabet. This is an important concept, as each user has a separate
file containing his information. The first letter of the username
determines the location of the user's file. For example, the
user "bob" has his file stored in /tcb/files/auth/b/bob,
as illustrated in Figure 2.
As illustrated, there are many similarities between the /etc/shadow
file and the data stored in the Trusted Computing Base. The u_name
and u_id entries map the contents of the file to a specific
user, which is found in /etc/passwd. The encrypted password
is stored here, although it will typically use the traditional DES
form of encryption. Like /etc/shadow, the TCB records store
when the user last changed his password; but unlike /etc/shadow,
it records when the last unsuccessful attempt was made to change
The TCB file also records the date of the last successful and
unsuccessful logins and specifies which terminal was used. This
is used to print the last login information when the user completes
the login process. Finally, the file also stores the number of unsuccessful
login attempts to allow disabling the account when the threshold
has been reached.
This file is missing the password expiration details. These are
stored in a different file in the TCB as it forms the password policy
and is applied to all users on the system. Recall the /etc/shadow
file allows for different values for each user, which can apply
an improved level of granularity to the protection of more privileged
The IBM AIX system uses yet another implementation to establish
a shadow file. The password shadows are stored in /etc/security/passwd.
The format of the file is shown in Figure 3.
The /etc/security/password file contains the user information
like the shadow file, but broken into what IBM calls "stanzas".
Each stanza contains the information for a particular user. However,
the password aging information is stored in another file, /etc/security/user,
which will be examined later in this article. The sample /etc/security/passwd
entry shown in Figure 3 illustrates the parameters available for
each user, which are explained in Table 1.
As previously mentioned, the /etc/security/passwd file
does not contain password aging, last change dates, etc., as traditionally
found in the /etc/shadow file. This information is found
in /etc/security/user (see Figure 4).
Like the /etc/security/password file, the user information
is separated into stanzas. A variety of information is configured
in the file, but we are most interested in the entries shown in
Table 2 regarding password aging and controls.
The functionality provided by the /etc/security/user file
is extensive for controlling both password aging and password quality.
Password quality is the most significant control a security officer
or auditor can look for. Poor password quality indicates a lower
level of effort required to gain unauthorized access to the system.
Additionally, good password quality does not mean the implementation
of randomly generated passwords, only that the users must be educated
and the appropriate system checks engaged to enforce them.
Understanding Password Quality
Simply having a password longer than six characters is not enough
to guarantee security. These frequently used choices are to be avoided
at all costs:
- Your name;
- Your spouse's name;
- Your pet's name;
- Your child's name;
- Names of friends, family, or co-workers;
- Names of cartoon or fantasy characters;
- Any "circular" shift of a name such as those above;
- The name of the operating system you are using;
- Anything visible from your desk;
- The street you live on;
- Your social insurance/driver's license numbers;
- Well-known cult words like "wizard", "gandalf",
"guru", and the like;
- Any user name;
- Any word that appears in the dictionary;
- Any place in the world;
- Any proper noun;
- Simple patterns like "qwerty" or "abcdefg";
- Words or phrases from television shows or movies like "NCC-1701";
- Repeats of the same letter.
The validation of password quality is essential to ensuring the
strength of the password as a control. The validation of the password
quality must be done when the password is set. While it is possible
to perform validation after the fact by using programs such as crack,
this is not as effective as many people believe. The validation
of the password must be based upon a series of rules that can be
customized to suit the needs of the particular organization. Not
all operating systems or application environments provide this level
of functionality in their design. Nonetheless, where it is available,
it is important to use it. However, in some situations, the value
of the validation performed is almost worthless due to the nature
of the application. For example, if an application offers the ability
to check passwords against a dictionary, but is not capable of performing
additional rule-based validation, the strength of the dictionary
can determine if the control is worthless.
The reasons for implementation of password rules at the time the
password is set are:
- Passwords can be cracked by brute force;
- Passwords can be cracked through dictionary searches;
- Passwords can be transmitted in the clear across an unprotected
- Passwords are often shared among groups;
- Users choose low-quality passwords.
The reality of these issues makes the validation of the passwords
upon creation even more important. However, not all UNIX systems
provide password validation rules. On those systems that do, the
full extent of the available validation must be used, including
pattern matching and character substitutions. In environments where
this cannot be accomplished, three additional methods are available:
replacing the password program itself, policy, and detective controls.
Replacing the /bin/passwd program with one that supports
the enhanced validation rules is the preferable approach, since
the benefits outweigh the initial cost of implementation over time.
Additionally, a number of these programs are available on the Internet,
so the organization does not need to develop one of its own.
The security policy component requires that users be educated
to establish high-quality passwords. However, users being users,
this is not something to be dependent upon. Consequently, detective
controls through programs such as crack must be used to find those
low-quality passwords and have the users correct them. Additionally,
ongoing requests must be made of the UNIX or application vendor
to provide the enhanced functionality.
The remaining question is "What is a good quality password?"
The password should meet the following criteria:
- Be at least 8 characters in length;
- Contain both upper- and lower-case characters;
- At least one number;
- At least one special character;
- Not based upon a dictionary word.
Many articles and discussions have focused on the quality of the
password itself, and this discussion is not to focus on that topic.
The Validity of the Password Cracker
A password cracker is a program that attempts to "guess"
the encrypted passwords in the /etc/passwd file by comparing
them to words in a dictionary. The success of the cracker program
dependens upon the CPU resources, the quality of the dictionary,
and the fact that the user has a copy of /etc/passwd.
With the increasing sophistication of online UNIX password cracking
software and the increase in computing power available to such sophisticated
cracking software, password quality is more crucial. For example,
the average desktop machine (low-end Pentium running Windows 95)
is capable of searching at a rate of about 50,000 passwords per
second. This has wide-ranging implications when examining password
Consider the following examples:
- A six-character password using a combination of uppercase,
lowercase, and digits can be cracked in 626 or 56,800,235,584
attempts. This is equivalent to 15.78 hrs.
- A seven-character passwords using a combination of uppercase,
lowercase, and digits can be cracked in 627 or 3,521,614,606,208
attempts. This is equivalent to about 41 days.
- An eight-character password using a combination of uppercase,
lowercase, and digits can be cracked in 628 or 2.183401055849e+14
attempts. This is equivalent to about 7 years.
- An eight-character password using only lowercase or only uppercase
characters can be cracked in 268 or 208,827,064,576 attempts.
This is equivalent to about 24 days.
- An eight-character password (or PIN) using only digits can
be cracked in 108 or 100,000,000. This is equivalent to about
Even the MD5 encryption code from the Linux PAM module states:
* and now, just to make sure things don't run too fast
* On a 60 Mhz Pentium this takes 34 msec, so you would
* need 30 seconds to build a 1000 entry dictionary...
meaning it would not take a lot of time on today's computing
platforms to crack a password.
When you examine the amount of time it takes, it is obvious why
attackers first try to get the system password file and then process
it looking for weak passwords. It is fairly easy to write a password
cracker: approximately 60 lines of C language or 40 lines of Perl
code will do it. If, as part of your attempt to provide for better
passwords on your system, you decide to write such a program, be
warned that you may be inviting disaster. Since an efficient cracker
program could be stolen and subsequently used to gain access to
other machines, if your program works, you may have further compromised
the security of your machine.
One of the most popular UNIX password cracking programs is crack,
by Alex Moffett. Tools such as crack work by searching dictionaries
of English (and other languages) words and phrases. They try various
permutations of words and phrases (backwards, prefixed or suffixed
by a digit, two short words concatenated together, reversed, etc.),
along with more simple heuristics, such as dates, permutations of
login ID, postal codes, and certain common phrases. Some of these
tools are extremely fast and will find dictionary words, such as
"ferreted", in a matter of minutes.
Although password cracking can be used to measure the effectiveness
and quality of the passwords selected by the users, a much better
approach is to fully utilize the capabilities of the UNIX logical
security environment. Remember, on their own, people choose passwords
that are easy to remember and, consequently, easy to guess or "crack",
weakening the overall security posture that the organization is
working to establish and maintain.
While the UNIX password mechanism has been a source of much controversy,
and has suffered through repeated attacks, the mechanism is a robust
control to prevent unauthorized access to the system. This statement
is true when the login controls are properly set up to force high-quality
passwords, evaluate them when they are created, and establish limits
for failed access, disabling accounts, and password aging. Of critical
importance is ensuring the actual encrypted passwords are not visible
to non-administrative users, and appropriate controls are in place
for FTP to prevent anyone from downloading them. Finally, before
using any password evaluation software, such as Oracle, get management's
permission to perform analysis to prevent action against you by
The author expresses his thanks to the people who reviewed this
article prior to its publication. The author extends a special thanks
to Mignona Cote for her unending support in his research and writing
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.