| ]

Authentication is an important aspect of security in an open source operating system such as Linux. To secure a Linux system, you have to customize the Linux Operating System (OS). Linux contains several authentication modules, such as Pluggable Authentication Module (PAM), shadow passwords, and MD5 authentication, that help authenticate end users, control access to strings of encrypted passwords, and reinforce high quality encryption.

This ReferencePoint describes three Linux authentication modules: PAM, shadow passwords, and MD5 passwords.

PAM

PAM is an easy and flexible way to authenticate end users. Before PAM became available, a program that required authentication had to use either its own authentication scheme or a default scheme, such as Data Encryption Standard (DES), packaged with the program. Implementing a custom or proprietary authentication scheme can result in unauthorized access if, as is often the case, the scheme is poorly written. Alternatively, implementing the default system authentication scheme means embedding function calls to its libraries and writing the entire authentication system for the protocol. As a result, the entire program has to be rewritten and recompiled whenever there is a change in the authentication mechanism.

PAM helps plug in new authentication programs that are independent of the default system authentication programs. It enables you to set up and change authentication policies without changing the existing programs. A combination of software and hardware authentication tools helps authenticate end users.

Advantages of PAM

The advantages of the PAM framework are:

  • It allows you to choose the authentication mechanism required for your system. It also handles simple authentications, such as passwords, as well as hardware authentication devices, such as smart and biometric cards.

  • It enables you to configure authentication for individual users and applications.

  • It allows you to use multiple password authentications for higher security.

How PAM Works

PAM contains library files and run-time pluggable modules that provide authentication-related services. Various applications, such as ftp, telnet, and logon, use the PAM library. A PAM module contains four functional components: authentication, account, session, and password.

An application uses the PAM library to access the appropriate functions in the module. The library file defines the modules to be used with the application. The response from the module is sent to the application through the PAM library.

For example, if an end user tries to change the password, the PAM library invokes the password component present in the module to change the password.

Figure 4-8-1 shows how PAM works:

This figure shows how PAM works.
Figure 4-8-1: How PAM Works

PAM Files

PAM contains several library, module, and configuration files that enable authenticating end users and applications.

PAM Library

This library provides functions to implement basic authentication and maintain authenticated sessions. It also helps create PAM-aware programs, which implement the functionality of PAM for end-user authentication. The PAM-aware program cannot use the facilities provided by PAM unless you use the functionality provided by the PAM library.

PAM Configuration Files

The PAM configuration files are stored in the directory /etc/pam.d/. In the earlier versions of PAM, all configuration files were stored in a file called pam.conf that was stored in the /etc/ directory. Every application that uses the PAM interface creates its own file within the /etc/pam.d/ directory. Each file is named after the service it controls. For example, if the ftp application uses the PAM interface for end-user authentication, a file named ftp is created in the /etc/pam.d/ directory. These files have a specific layout that contains links to the modules to be executed. These modules are located in the /lib/security/ directory.

The PAM configuration file contains a list of authentication functions that are used by the program. The file contains the following elements:

  • Service name: Specifies the name of the service

  • Module type: Identifies the model type of the service

  • Control flag: Indicates the continuation and failure statistics for the model

  • Module path: Specifies the path name where the module is stored

  • Module options: Indicates arguments that are passed to the service modules for additional functionality

Contents of the PAM Configuration File

The PAM configuration file contains a description of the module type, the control flag, the module path, and module arguments.

Module Type

This describes the type of functionality used by a particular application. The modules can be of auth, account, password, and session types. Of these, auth and password are most commonly used.

Control Flags

A PAM module generates a successful or failed result when it is executed. Control flags handle this result and designate the importance of a module. There are four types of control flags defined by PAM standards:

  • required: States that the module must be checked to allow authentication. When the check fails, the end user is not notified until all other modules of the same type have been checked.

  • requisite: Maintains that the module must be checked for the authentication to be successful. If the check fails, the end user is notified immediately.

  • sufficient: Ignores all module checks if this check fails. If the check is successful and no other module before it has failed, the end user is authenticated without checking the remaining modules.

  • optional: Executes the default module for authentication when all other modules fail. This check does not affect the overall success or failure of that module type.

Module Path

This path links to the pluggable module used by the application. Usually, the complete path, such as /lib/security/pam_stack.so, is provided in the module path. If the full path is not specified, this module is assumed to be in the default /lib/security/ directory.

Module Arguments

PAM uses arguments to pass additional information to the module during authentication. This allows the PAM configuration file to use the module according to the additional arguments entered.

Table 4-8-1 lists the arguments handled by PAM modules:

Table 4-8-1: PAM Arguments
Open table as spreadsheet

Argument

Description

Audit

Logs information. Is an extensive form of debug.

Bigcrypt

Uses the DEC C2 extension to crypt().

Debug

Logs information using syslog.

md5

Uses MD5 encryption instead of crypt().

Nis

Uses Network Information Service (NIS) passwords.

Nodelay

Asks for the default delay to be removed. By default, if a password failure occurs, the module waits for one second before asking for the password again.

not_set_pass

Does not use passwords from other modules, nor does it share the password with other modules.

Nullok

Allows the end user to enter a blank password.

Remember

Saves recent passwords to prevent end users from altering passwords.

try_first_pass

Uses the password from the previous auth module and prompts for a new password if the retrieved password is blank or incorrect.

use_authtok

Sets the new password to that used by the previous module.

use_first_pass

Uses the result from the previous stacked auth module; never prompts the end user for a password.

Working of a PAM Configuration File

When an application requests PAM for authentication, the PAM configuration file of that application invokes the modules that will authenticate the end user. Figure 4-8-2 shows a PAM configuration file:

Click to collapse
Figure 4-8-2: PAM Configuration File

In this figure:

  • The first line starting with a # character denotes a comment entry. In this case, the comment denotes that the file is a PAM configuration file.

  • The second line ensures that the root user logs on from a secured terminal, such as telnet and login. Secure terminals are listed in the /lib/security folder.

  • The third line allows the end user to enter the password that is checked using the information stored in the /etc/passwd/ file. If the password exists, PAM checks the password in the /etc/shadow file for a match. The pam_unix.so module automatically detects the shadow passwords stored in the /etc/shadow file to authenticate end users. The argument nullok instructs the pam_unix.so module to allow a blank password.

  • The fourth line is the final authentication step. PAM checks whether the file /etc/nologin exists, and terminates the authentication if the end user is not the root user.


Note

In this configuration file, all three auth modules are checked, even if the first one fails.

  • The fifth line carries out the necessary account verification. Module pam_unix.so checks whether the account has expired, and whether the end user has changed the password within the specified period.

  • In the sixth line, pam_cracklib.so prompts for a new password if the password has expired. With the help of the attribute retry=3, the end user is given two more chances to enter a strong password, which is a password that follows the rules set by the OS for setting passwords. For example, if an OS requires a combination of alphanumeric characters, the passwords accepting this rule are accepted as strong passwords.

  • The seventh line specifies that pam_unix.so be used whenever the user changes the password using the passwd command. The shadow argument informs the module to create a shadow password while updating the end-user password. The argument nullok informs the module to accept a blank password when updating the end-user password.

  • The final line specifies that pam_unix.so will manage the session component. The username and the service type are logged onto a file named /var/log/messages at the beginning and end of the session.


PAM Module

PAM is implemented as an Application Programming Interface (API) with a series of modules that authenticate end users in Linux. These modules are executable binary files that implement specific mechanisms, such as authentication, password, session, and account. Each module contains at least one module type. These files are loaded in the PAM interface library. PAM libraries are stored in the directory /etc/pam.d/, which directs application requests to the appropriate module for authentication. These modules are dynamically loadable objects and are located in the directory /etc/lib/security.

A PAM module can be added at any time. This new module can then be used by any application that uses the PAM framework. When a module is created for a specific application, any application using the PAM framework can immediately use the module without being recompiled.

Module Types

There are four authentication management components in a module: account management, authentication management, password management, and session management.

Account Management

This provides account verification services. It handles issues pertaining to the end-user account, such as account validity and password expiration.

Authentication Management

This provides end-user authentication services, such as user name and password verification. It uses the end user’s password to verify whether he or she is authentic and should be given access to accounts. PAM modules can easily be integrated with hardware-based authentication devices. This type of authentication can be performed using smart cards and biometric devices.

Password Management

The function of this module is to change passwords.

Session Management

This handles the task of opening and closing authenticated sessions. It also allows setting resource limits for users.

Basic PAM Modules

The PAM modules are stored in the /etc/lib/security directory with a .so extension. Some basic modules used by the PAM library for authentication are:

pam_unix.so

This module provides authentication services, such as password and end-user management services. It verifies the end-user information against the information stored in the /etc/passwd and /etc/shadow file. This module contains:

  • Account component: Validates the end-user account and password and advises the end user to change the password after a specified period of time. It handles the audit and the debug arguments.

  • Authentication component: Checks the end-user password against the password database.

  • Password component: Changes the end-user password. The module pam_cracklib can be added with this component to check password security.

  • Session component: Logs the end-user name and the session type to the syslog file, at the start and end of the end-user session. This component does not handle any arguments.

pam_warn.so

This module logs information to syslog about any attempts to change authentication and passwords. It contains auth and password components and does not handle any arguments.

pam_deny.so

This module blocks access to the application. There are three components in this module:

  • Authentication component: Prevents the end user from authenticating or starting the application.

  • Password component: Prevents the end user from changing the password.

  • Session component: Shows messages and prevents the end user from starting a shell.

pam_nologin.so

This module prevents end users, other than the root, from logging on whenever the system is performing an important process, such as a shutdown. It contains no arguments and has only an auth component.

pam_cracklib.so

This module provides additional strength for checking passwords when plugged into the password stack of a given application. It contains a password component that prompts the end user for the password. It checks the password’s strength against the system dictionary and against a set of rules for identifying weak passwords.

This module ensures that an end user selects a satisfactory password. It checks the strength of the password by performing checks, such as:

  • Palindrome: Checks whether the new password is a palindrome of the old one.

  • Case change only: Checks whether the new password is the same as the old one, with only a change of case.

  • Similar: Checks whether the new password is similar to the old one.

  • Simple: Checks whether the new password is too small.

  • Already Used: Checks whether the password has been used previously. All previous passwords are stored in the /etc/security/passwd file.

pam_ftp.so

This module provides a pluggable anonymous ftp mode of access. The authentication component intercepts the user name and password for end-user authentication.

pam_group.so

This module provides group settings, based on the user name and the terminal from which a given service is requested. It contains an authentication component that does not authenticate end users, but grants a group membership to the end user. This membership is granted based on services requested.

pam_krb4.so

This module, known as the Kerberos module, provides an interface for verification of end-user passwords. It grants access by destroying the end user access at logout time and changing a Kerberos password. There are three components in this module:

  • Session component: Sets the user’s KRBTKFILE environment variable and deletes the user’s ticket file during logout.

  • Password component: Changes the end user's Kerberos password by first getting the old password and using it to invoke the password changing service. The new password entered by the end user is sent to the service to change the password.

  • Authentication component: Verifies the end user’s Kerberos password by requesting a ticket from the Kerberos server. It creates a ticket file for the end user and deletes it when the end user logs out.

pam_lastlog.so

This module maintains the lastlog file stored in the /etc/log/ directory. When the end user logs into the system, the session component of the module provides the last logon message. This module handles six arguments:

  • debug: Writes information to the syslog file

  • nodate: Does not give the date of the last logon, when showing information about it

  • noterm: Does not show the terminal name on which the last logon was attempted

  • nohost: Neglects to shows the host name from which the last logon was attempted

  • silent: Neglects to shows any information about the last logon

  • never: Indicates that the end user has not previously logged on if the lastlog file contains no old entries of the end user

pam_mail.so

This module can be plugged into any application for checking mail messages. The default location of the mail file is /var/spool/mail. The module shows a single message that indicates a new mail message in the mail folder. This module handles seven arguments:

  • debug: Writes information to the syslog.

  • dir-pathname: Allows specifying the path of an alternative directory to search for new mail messages.

  • nopen: Instructs the module not to print any mail information when the end-user credentials are acquired. This control flag enables the MAIL environment variable, but does not print any information about it.

  • close: Informs the end user about any new mail messages after the end-user credentials are revoked.

  • noenv: Does not set the MAIL environment variable.

  • empty: Indicates that the end-user mail directory is empty.

  • quite: Reports only when there is a new mail message.

pam_pwdb.so

This module is a pluggable replacement for the pam_unix module. It provides authentication services in the absence of standard /etc/passwd and /etc/shadow files for authentication and password storage. There are four components of this module:

  • Account component: Performs accounting functions. Establishes the status of the end-user account and password. It advises the end user to change his or her password after the allotted period of time and delays providing services to the end user until the password has changed.

  • Authentication component: Provides authentication by validating end-user credentials. It does not permit the end user to access the services if the password is blank, but the nullok argument can override it.

  • Password component: Updates end-user passwords.

  • Session component: Logs the user name and the service type provided to the end user in the syslog file. Messages are logged at the beginning and end of the end-user session.

pam_rhosts_auth.so

This module performs network authentication for services. This module is based on the contents of the files /etc/hosts.equiv and /.rhosts. The following flags modify the behavior of the module:

  • no_host_equiv: Ignores the contents of the /etc/hosts.equi file.

  • hosts_equiv_rootok: Allows the use of /etc/hosts.equi to the superuser account. Without this option, the superuser account is not activated.

  • no_rhosts: Ignores the contents of the end-user personal configuration file /.rhosts.

  • privategroup: Overwrites the group write access when the name of the authenticated end user is the same as that of the group owner of the file. By default, the /.rhost file can be modified only by the owner of the file.

  • suppress: Prevents the module from writing messages to the syslog file.

pam_rootok.so

This module is used when the root user tries to gain access to a service without entering the password. It authenticates that the root user uid is 0.

pam_userdb.so

This module uses a database to verify the username and password against the password in the Berkeley DB database. Username and the corresponding data fields are indexed in the database. Information is stored in the database in an unencrypted format.

Shadow Passwords

In Linux, end-user information, such as username and password, is stored in the /etc/passwd file. All information is stored in an encoded format using the crypt() function, which implements the DES algorithm. When an end user specifies a password and user account, the password is encoded in 4096 ways with a randomly generated value called salt. The salt value and the encoded password are stored in the passwd file. When the end user logs on and supplies the password, this value is compared with the salt value and the encoded password. If they match, the end user is authenticated.

Information stored in the /etc/passwd file can be read by any end user. Hackers can easily encrypt this information and gain unauthorized access to the system and its resources. Securing the passwd file is critical to avoid unauthorized access to the system. The shadow suite was developed to secure the system.

Overview of Shadow Passwords

In most Linux distributions, the shadow suite is installed by default. This suite contains various features, such as shadow passwords, utilities for adding, modifying, and deleting end-user accounts and groups, and secondary authentication programs.

The shadow password relocates the contents of the /etc/passwd file to another file, the /etc/shadow/ file. End users other than the root user cannot access this information, so the system is protected against hackers.

The shadow suite contains replacements for programs such as su, login, passwd, newgrp, chfn, chsh, and id. The packages also contain new programs such as change, newusers, dpasswd, useradd, userdel, usermod, groupadd, groupdel, groupmod, groups, pwck, grpck, lastlog, pwconv, and pwunconv.

Format of the /etc/passwd File

The /etc/passwd file contains end-user information in username:passwd:UID:GID:full_name:directory:shell format where:

  • username: Denotes the end user’s logon name

  • passwd: Indicates the encoded end-user password

  • UID: Specifies the numerical end-user ID

  • GID: Denotes the numerical default

  • full_name: Indicates the end user’s full name

  • directory: Specifies the end user’s home directory

  • shell: Denotes the end user’s logon shell

Format of the /etc/shadow File

The /etc/shadow file contains end-user information in the following format:

username:passwd:last:may:must:warn:expire:disable:reserved 

Here:

  • username: Denotes the end user’s logon name

  • passwd: Specifies the encoded end-user password

  • last: Indicates the number of days since the password was last changed

  • may: Denotes the day before which the password may be changed

  • must: Identifies the day after which the password must be changed

  • warn: Indicates the days before the expiration of the password and warns the end user

  • expire: Specifies the days after which the password expires

  • disable: Denotes the days since the account was disabled

  • reserved: Specifies a reserved field


MD5 Passwords

The MD5 algorithm is an extension of the MD4 algorithm. The MD5 algorithm takes an input of arbitrary length and produces a 128-bit output. This algorithm creates digital signatures where a large file name is compressed and encrypted. The MD5 algorithm is fast on 32-bit machines. MD5 does not require large substitution tables, but needs an algorithm that can be coded efficiently.


Note

To know more about MD5, see the Intrusion Detection in Linux ReferencePoint.

MD5 Algorithm

MD5 helps encrypt email and sensitive documents. Traditionally, Linux passwords were encrypted using the standard crypt() function, which implements the DES algorithm. This algorithm was not strong enough for the current systems that could be easily hacked. In DES, only the first 8 characters of the password are significant, while the others are ignored.

Modifying the algorithm to use larger passwords was not an option because of the way DES worked. It often became easier to crack passwords that were 16 characters long instead of 8. MD5 later developed, was much stronger and used a scheme that allowed passwords to be of any length. The more the characters, the better it is for security.

MD5 is a hashing algorithm. It can take a variable size input and return a fixed size string as output. This output, also known as the hash value, can be used as a digital fingerprint. The MD5 algorithm ensures that it is impossible for two non-identical messages to be run through it and to produce an identical fingerprint. This fingerprint is called a message digest. It tries not to create a message that will produce a pre-specified target message digest. The MD5 algorithm is intended for digital signature applications, where a large file must be compressed in a secure manner before being encrypted with a private key under a public-key cryptosystem, such as RSA.

Checking for MD5 Passwords

Almost every Linux distributor ships systems that are capable of handling MD5 passwords. MD5 is not enabled by default in some distributions. To see if your distribution has MD5 passwords, count the number of characters in the password field of the /etc/shadow or /etc/passwd file. If the password field has entries with only 13 characters, DES is being used. If MD5 is being used, it will have 34 characters. Another identifying feature is that MD5 passwords always begin with the sequence $1$.

Enabling MD5

If your distribution does not have MD5 enabled, select the /etc/pam.d directory and edit each file in the directory. Add the keyword md5 to all lines that mention the password and mention either pam_unix.so or pam_pwcheck.so.

In Red Hat and Mandrake distributions, you can enable password generation with MD5 by giving the following command at the command prompt:

authconfig --enablemd5

To disable MD5, use this command:

authconfig --disablemd5