UNIX System Administration Handbook - Evi Nemeth [388]
Red Hat’s authentication model is based on pluggable authentication modules, also known as PAM. As a result, passwd under Red Hat uses a PAM ruleset to validate passwords. You can configure its rules in the file /etc/pam.d/passwd. Learn more about PAM at http://parc.power.net/morgan/Linux-PAM/index.html.
Shadow passwords
Traditionally, each line in /etc/passwd consists of seven fields. The second field contains a string that represents the user’s encrypted password. Since /etc/passwd must be world-readable for commands like ls to work, the encrypted password string is available to all users on the system. Evildoers can encrypt selected dictionaries or words and compare the results with the strings in /etc/passwd. If the encrypted strings match, a password has been found.
See page 666 for more information about password guessing.
How much of a threat is this? In the 80s, there was at least one way to decrypt passwords posthaste,3
but run-of-the-mill hackers had to be content with using the crypt library routine4
to encrypt dictionary words for comparison. A “fast” machine in the 80s could do a few hundred encryptions per second. In 1998, John Gilmore of the Electronic Frontier Foundation and cryptographer Paul Kocher cracked a 56-bit DES key in 56 hours, using a brute force search. Recent proposals suggest that a $1 million special-purpose computer could crack any 56-bit DES key in just a few hours.
These results are frightening, and they suggest that user access to encrypted password strings really ought to be restricted. A common way to impose restrictions is to put passwords in a separate file that is readable only by root, leaving the rest of /etc/passwd intact. The file that contains the actual password information is then called the shadow password file (often, it is /etc/shadow). Most UNIX vendors support shadow passwords, as do all of our example systems.
HP-UX requires you to install its optional “trusted system” package to get shadow passwords. The package includes a number of additional security enhancements, but it adds considerable complexity to the administration of users and passwords.
Group logins and shared logins
Any login that is used by more than one person is bad news. Group logins (such as “guest” or “demo”) are sure terrain for hackers to homestead. Don’t allow them at your site.
Likewise, don’t allow users to share logins with family or friends. If little Johnny needs a login to work on his science project, give him one with that stated purpose. It’s much easier to take away Johnny’s login when he abuses it than to get rid of Dad and his account, especially at government sites.
See page 780 for some additional comments on shared logins.
At most sites, “root” is a group login. Dangerous! We recommend using the sudo program to control access to rootly powers. See page 41.
Password aging
Most systems that have shadow passwords also allow you to compel users to change their passwords periodically, a facility known as password aging. This may seem like a good idea at first glance, but it has several problems. Users often become resentful at having to change their passwords, and since they don’t want to forget the new password, they choose something simple that is easy to type and remember. Many users switch between two passwords each time they are forced to change, defeating the purpose of password aging.
Nevertheless, passwords should be changed regularly, especially the root password. A root password should roll easily off the fingers so that it can be typed quickly and cannot be guessed by someone watching the movement of fingers on the keyboard. At our site most people use sudo rather than the real root password, but we select the root password carefully all the same.
See page 41 for more information about sudo.
User shells
Do not use a script as the shell for an unrestricted (passwordless) login. Passwordless logins should be used only as a facility for running small, noninteractive utilities