Cover V07, I08
Table 1


Securing UNIX Passwords

Eric Davis

Password security has plagued systems administrators for many years. Publicly available password guessing applications can crack passwords using brute force techniques with massive dictionary word lists. The most notable password guesser, Alec Muffett's Crack, is a simple, smart, and powerful application. It is common that Crack will guess a significant number of the passwords on a system where password requirements are not being enforced. The system administrator cannot rely on the user to choose strong, difficult to guess passwords. The only way to enforce certain password requirements is to do it when users change their passwords. Hence, the UNIX password program must be evaluated.

Before looking at the various password programs, the importance of the /etc/passwd file must be addressed along with the characteristics of passwords. The password is the most important aspect of securing a UNIX system. Crackers can easily enter a system using a guessed password and then spoof their way to root via well-known operating system security holes. If the door can be slammed on potential crackers with a robust password file, most of the easier avenues of attack will be sealed.

Cracking Passwords

Most UNIX systems support the use of shadow passwords. The common /etc/passwd file stores information about all the user accounts on the system. This information includes the encrypted password, uid, gid, home directory, shell, etc. The /etc/passwd file must be world readable so applications like ls can translate uids and gids. If shadow passwords are used, then the encrypted password field in the /etc/passwd file is "starred" out (i.e., replaced with a *). The encrypted password is then stored in the /etc/shadow file. This file is readable only by root, eliminating the possibility of a regular user grabbing encrypted password strings and running Crack against them. Note that only a few applications use the encrypted password field. These applications include su, login, and xlock, and must be setuid root.

The dictionaries used by Crack are huge and range from the normal to the bizarre (e.g. Star Trek words dictionary). Crack tests each word in these dictionaries for each mangling rule specified. These mangling rules are easily configurable and can tell Crack to test a word written backwards, with punctuation at the end, punctuation at the beginning, replacing every "t" with a "3", capitalized, etc. It is possible to configure Crack to use as many mangling rules as wanted. Crack comes with many dictionaries totaling more than a million words and approximately 500 mangling rules. Additional dictionaries and mangling rules can also be found on the Internet.

Because Crack can guess simple passwords, and can be configured to guess some stronger ones, users need to choose passwords that are not easily cracked. Passwords that are easier to guess are ones that, for example: can be found in a dictionary, use some variant of the login name, or contain all lower or uppercase characters. A password should be at least six to eight characters long, and contain a mixture of lowercase, uppercase, numeric, and special characters. The objective when choosing a password is to make it as obscure as possible, eliminating the possibility of the cracker making educated guesses. This leaves no alternative but a brute force search trying every possible combination of letters, numbers, and punctuation characters.

Not only are the contents of the password important, but so is the length. Consider the following. The total number of permutations between six and eight character passwords, that contain exactly three non-lowercase characters, is so significant that it's worth making the user remember two extra characters. Difference: 17 billion (six characters) vs. 33 trillion (eight characters). A brute force search on an eight character-password would take well over one thousand years to complete using a machine that could test approximately five thousand passwords per second.

It is also very important for users to select a password that is completely different from the old. If a user's old password gets cracked, the cracker will most likely try to guess the new password using simple modifications to the old password. Users have a tendency to choose a new password that differs from the old by only a couple characters. Most password programs test to ensure that old and new passwords differ by at least three characters. Password policies should also forbid users from changing back to a favorite password after password-aging programs have forced them to select a new one.

UNIX Password Programs

Most of the default password programs shipped with UNIX operating systems are not able to protect the system from password crackers. They don't have the capability to allow the system administrator to enforce password construction requirements. Additionally, the interfaces (command line arguments) are different across platforms, making it more difficult for the system administrator.

After examining the password programs for Solaris, IRIX, SunOS, and FreeBSD, it was determined that SunOS was the most strict in enforcing password requirements. Unfortunately, they all allowed passwords that could be guessed using Crack's default configuration. They did not allow an all lowercase password and forced the use of at least one uppercase, numeric, or special character, but that isn't enough. SunOS goes a step further and enforces that a password must have three of the following four character types: lowercase, uppercase, numeric, and special. Both Solaris and SunOS required an eight-character password, but IRIX and FreeBSD allowed a six-character password. FreeBSD was the only OS that did not enforce a minimum number of different characters between the old and new passwords, allowing the user to change their password without actually changing it.

Some public domain password programs can be used as drop-in replacements for the weaker default password programs. These public domain programs have been ported to a variety of UNIX variants. The two programs evaluated were Passwd+ and Npasswd.

Passwd+, written by Matt Bishop, is fully configurable to allow the system administrator to enforce specific password requirements. Passwd+ uses a configuration file that is read at run time to specify the password requirements. This means that Passwd+'s configuration file must be protected as well as maintained. Unfortunately, it appears that Passwd+ is no longer supported, because there haven't been any updates or modifications in the past few years.

Npasswd, written by Clyde Hoover, is another good password checker. Npasswd is unique in that it offers full support for NIS/NIS+. Like Passwd+, Npasswd uses a run time configuration file to specify password requirements. Another feature offered by Npasswd is a database of old passwords. The system administrator can set the depth of this database to prevent a user from reusing an old password. Npasswd is fully supported and is currently being maintained by Clyde Hoover.


At first, the Security Team at the Numerical Aerospace Simulation (NAS) Facility attempted to modify each vendor's passwd application to enforce the facility's password requirements. Since most of the code is proprietary and hard to get, and the interfaces to each of these applications are mostly different, the administration was extremely difficult. Needless to say, the team gave up on the vendor's sources and analyzed both Passwd+ and Npasswd. Both of these public domain applications were attractive but did not fulfill the requirements at the NAS Facility. The NAS does not not use NIS/NIS+, and the Security Team did not want to use or maintain a runtime configuration file for the password application. For these reasons it was decided to create a new password application, Epasswd, that is able to meet the password construction requirements for all systems as well as minimize the associated administration.

Epasswd is different from Passwd+ and Npasswd in that configuration is done at compile time. Epasswd offers a unique configuration feature for enforcing certain characters to occur in the middle of the password. Often a user will choose a password that is a common word and insert a number or special character as the first or last character. Crack is able to guess these passwords easily. Epasswd is fully supported and currently being maintained with an effort to port it to as many UNIX variants as possible.

Configuration and Use of Epasswd

The Security Team at the NAS Facility has been using Epasswd for more than a year. The team has continually run Crack for that time, and Crack has been unable to guess any new passwords created using Epasswd. Epasswd has proven itself as a good replacement for the UNIX password application. Here is a simple overview of the configuration and use of Epasswd. As already mentioned, Epasswd is configured at compile time, so there is no run-time configuration file to be maintained. Unfortunately, if the password requirements change, Epasswd must be recompiled with the new requirements and re-installed. To change the requirements while using Passwd+ or Npasswd, simply update the necessary configuration file. Epasswd offers the following options for specifying how passwords should be constructed (see Table 1):

  • Minimum length: Prevents the use of short passwords with a small number of permutations.

  • Maximum length: Some UNIX 'crypt' library calls only use the first eight characters in the password buffer.

  • Minimum lowercase [a-z]: Prevents the use of a password with all uppercase characters.

  • Minimum uppercase [A-Z]: Prevents the use of a password with all lowercase characters.

  • Minimum numeric [0-9]: Prevents the use of a password with all upper and/or lowercase characters.

  • Minimum special [~'!@$%^&*()-_+={}[]|\;:'"<>,./?<sp>]: Prevents the use of a password with all upper and/or lowercase characters.

  • Minimum tests that must pass: Specifies how many of the tests from minimum lowercase, minimum uppercase, minimum numeric, and minimum special the password must pass.

  • Uppercase middle: Specifies that if an uppercase character is used in the password, then it must exist somewhere in the middle of the password, not the first or last character.

  • Numeric middle: Specifies that if a numeric character is used in the password, then it must exist somewhere in the middle of the password.

  • Special middle: Specifies that if a special character is used in the password, then it must exist somewhere in the middle of the password.

  • Minimum different: Specifies the number of characters that must differ between the new and old passwords.

Epasswd offers all the normal operations expected from a password program and more. Note that Epasswd has full native support for the underlying OS's password implementation (e.g., password aging and shadow passwords). No modifications or additions are made to the underlying implementation, so there is no need to modify and re-compile other applications that depend on the underlying implementation.

Password aging allows the system administrator to specify the age characteristics of a password. There are three characteristics that can be specified. First is the maximum age. This specifies the number of days that the password is valid before it must be changed. Second is the minimum age. The minimum age specifies the number of days that must pass between password changes. This is used to prevent a user that is being forced to change their password from changing their password and then quickly changing it back to the original. The third characteristic is the warn time. The warn time specifies the number of days before a password must be changed to warn the user. The warning occurs when the user logs in.

Using Epasswd, the following command is used to set for user edavis, the password's maximum age to one year, the minimum age to one week, and the warn time to 3 days:

# passwd -x 365 -n 7 -w 3 edavis

To turn off password aging completely, simply specify -1 as the maximum age:

# passwd -x -1 edavis

The system administrator is also capable of both forcing a user to change his or her password immediately and locking a password to prevents future logins. To force a password change, simply specify 0 as the maximum age:

# passwd -x 0 edavis

Now the user edavis will be forced to change his password the next time he logs into the system. The system administrator also has the ability to lock a user's password. When locking a password, the encrypted password field in the /etc/passwd file is replaced with the string *LK*. Other password programs vary in the string used to lock an account. This is done using the following command:

# passwd -l edavis

When shadow passwords are used, some OSs offer extra features. On both Solaris and IRIX systems, it is possible to expire accounts. Epasswd takes advantage of this feature to allow the system administrator to expire an account immediately or set the date for an account to expire. For setting a date when an account expires, the date must be specified as the number of days since January 1, 1970. Fortunately, Epasswd has an option specifying the current date in the number of days since January 1, 1970 to help determine an expiration date:

# date
Sat May  2 16:39:17 PDT 1998
# passwd -v
Epasswd version: v1.1

uname: IRIX shark 6.3 12161207 IP32 Shadow passwords are currently being used. It has been 10348 days (1478 weeks) since January 1, 1970.

Here is how to set an account to expire on April 8, 1999:

# passwd -e 10690 edavis

Epasswd also lets the system administrator expire an account immediately:

# passwd -E edavis

Additionally, the system administrator can set the number of days of inactivity allowed for an account before expiring it. This eliminates the hassle of old unused accounts lingering on the system. Use the following command to set the allowed period of inactivity to one month:

# passwd -i 30 edavis

Epasswd offers some extra features not found in any other password program distributions. The first is a command line argument that is used to swap in an already encrypted password. This allows the administrator to easily distribute a user's password across multiple systems on which the user has an account. There is no need to cut and paste an encrypted password string while editing the password file. Second, is the utility Genpasswd. Genpasswd is a simple program that generates random passwords. It features a full set of command line options to specify how the password should be constructed. The options are very similar to Epasswd's compile time options listed above. Genpasswd is excellent when assigning an initial password to anew user account. The following command generates a password that is eight characters long, contains one uppercase character, two numeric characters, and one special character in the middle:

# genpasswd -l 8 -u 1 -n 2 -s 1 -S

Be careful when generating passwords using Genpasswd as they are presented in clear text. Transmitting a default password to the user in clear text opens the possibility of the password being compromised by a packet sniffer. it is best to generate and tell the user their new password in person.


The information presented here should not be overlooked. Take the time to run Crack on your systems and see how many unsecure passwords exist. It is the system administrator's responsibility to protect systems by ensuring that passwords are secure. Eliminating all unsecure passwords and turning on shadow passwords will help prevent break-ins. Check the documentation for your system's password application to ensure that simple passwords are not allowed. If they are, the public domain password applications to choose from (Passwd+, Npasswd, and Epasswd) have all proven to create strong hard to crack passwords.

Other Resources

Crack -

Epasswd -

Npasswd -

Passwd+ -

UNIX System Security by David A. Curry. Addison-Wesley Publishing Company.

UNIX System Administration Handbook by Nemeth, Snyder, Seebass, and Hein. Prentice Hall PTR.

Combinatorics by William Smoke. University of California Irvine.

About the Author

Eric Davis received a B.S. in Computer Science from UC Irvine and has been working for Sterling Software as a Network Engineer at the NASA Ames Research Center for the past two years. He is an avid C/C++ programmer with special interest in the BSD UNIX kernel. He can be reached at: