Revisiting UNIX Password Controls -- Part 2

Chris Hare

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 password.

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 accounts.

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;
• Birthdays;
• 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 network;
• 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 quality.

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 100 seconds.

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...
 */

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.

Summary

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 company.

Acknowledgements

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 activities.

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.