PAM is an authentication mechanism that originated on Solaris, but is used on various systems, including Linux. The Linux PAM implementation allows a system administrator to choose how users authenticate to various services. New modules can be added by an administrator at any time, offering overall flexibility in how authentication happens.
Traditionally, Linux and other Unix-like systems simply authenticated users against an entry in the file /etc/passwd. Everyone had read-only access to the password file, and the encrypted passwords were available to anyone with access to the system. This simple design made password files vulnerable to dictionary attacks, an attack where the attacker would encrypt common words and compare his encrypted words with what was in the password file. If a match was found, the attacker then would know the password. As a countermeasure, Linux and other Unix-like systems changed from the standard password file to a shadow password file, where passwords were moved out of the traditional /etc/passwd file into a different file (typically /etc/shadow). Since the /etc/passwd file needs to be readable by any user on the system, moving sensitive password hashes out of the world-readable file limited the availability of the hashes to the root user only.
Many experts believe that having a single authentication mechanism for each service on the system (terminal logins, local logins, network logins, etc.) is too inflexible. Typically, each service needed its own authentication code or had to use the single mechanism available. PAM is the answer to inflexible single authentication mechanisms. PAM allows different modules to be added for authenticating new services and for adding new authentication mechanisms for old services. PAM can also be used to enable shadow file authentication for applications that don t natively support it. PAM module information can be found in the following places on the Internet:
The Linux PAM resource page at kernel.org: http://www.kernel.org/pub/linux/libs/pam/modules.html
The OpenWall PAM page, which is where pam_passwdqc and pam_mktemp live: http://www.openwall.com/pam/
Freshmeat s PAM section: http:// freshmeat .net/search/?q=pam§ion=projects&x=0&y=0
Remember that PAM contains the keys to your system, so you should only run PAM modules that are from known sources and that you trust. Anything else may allow an attacker to access your system.
There are interesting modules for voice authentication, smart cards, tokens, and a host of other types. Make sure you either have a known good way to get in by experimenting on one service rather than a core function, or that you can boot to single user mode and recover the system if you decide to experiment.
PAM allows you to enable strong per-service authentication features, shadow passwords, stronger hashing functions, and change mechanisms due to changing system requirements. The flexibility comes with a small cost of increased complexity, outweighed by the benefits.
You can use a PAM module to enforce strict password requirements. Many administrators don t want their users passwords to be easy to guess, so they might require a strong password module to authenticate password changes.
Strong passwords are often difficult for users to remember. Their use should be weighed with the fact a user might write his password down and therefore accidentally make it available to a local attacker, balanced against remotely accessible services that may be open to common wordlist type dictionary attacks.
With PAM, you can require a user s password to contain a certain number of non-alphabetic and non-numeric characters , and adhere to a specific length requirement. On a standard ASCII keyboard, there are 26 letters , 10 digits, 32 symbols, and the space character. While a two-character password is hardly strong enough for most purposes, if it were two alphabetic characters, an attacker would only have to go through 32 different combinations before exhausting the possibilities. If the password is any keyboard character, then the attacker has to go through 138 potential combinations. With longer passwords the difference is even more pronounced.
By requiring a password to not include dictionary words, an administrator can further reduce the amount of success an attacker can have either on a blind attack against a user s account or even on cracking the password hash with a large dictionary program.
BSD-style Unix systems use a special form of group access to decide which users can use the su command to gain root access. Users who are authorized to gain root access are added to a specific system group, and only those users can change to root to perform administrative functions. This group is typically named wheel, and Linux administrators can add a PAM module to enable wheel group access to their machines.
Limiting access to only people who need to be able to perform functions that require root permissions makes it more difficult for an attacker to gain escalated privilege through a non-privileged account, such as that of a web server s process or a user who uses the same password on another compromised system.
Some administrators like to enable a central authentication server, so that users can authenticate with one password to multiple systems, and that password only has to be maintained in a single place. The most common of these is the Windows domain account through a domain controller or Active Directory. Another popular choice is a RADIUS server. RADIUS is supported by many dial-up systems used by ISPs, and it is also supported by RSA s SecureID ACE server protocol. An ACE server is a server that supports two-factor authentication using a hardware token that s time synchronized to the server and a PIN that the user knows . Large corporations often use ACE/SecureID to authenticate to important systems where security is an issue. By changing which PAM module is used to authenticate, an administrator may use one of these centralized services without any application changes.