Securing User Authentication

Many linux distributions ship with user authentication that is not adequately secure. This section discusses some of the ways you make user authentication secure on your system. While doing these things will make your system more secure, do not be so naive as to think they make you invulnerable.

A strong `/etc/pam.d/other`

All of the files in /etc/pam.d/ contain the configuration for a particular service. The notable exception to this rule is the /etc/pam.d/other file. This file contains the configuration for any services which do not have their own configuration file. For example, is the (imaginary) xyz service attempted authentication PAM would look for a /etc/pam.d/xyz file. Not finding one, authentication for xyz would be determined by the /etc/pam.d/other file. Since /etc/pam.d/other is the configuration to which PAM services fallback, it is important that it is secure. We will discuss two secure configurations of /etc/pam.d/other, one which is quite nearly paranoid and which is gentler.

A paranoid configuration

A paranoid configuration of /etc/pam.d/other is as follows:

    auth	required	pam_deny.so 
    auth	required	pam_warn.so 
    account	required	pam_deny.so 
    account	required	pam_warn.so 
    password	required	pam_deny.so 
    password	required	pam_warn.so 
    session	required	pam_deny.so 
    session	required	pam_warn.so

With this configuration, whenever an unknown service attempts to access any of the four configuration types, PAM denies authentication (via the pam_deny.so module) and then logs a syslog warning (via the pam_warn.so module). Short of a bug in PAM, this configuration is brutally secure. The only problem with that brutality is it may cause problems if your accidentally delete the configuration of another service. If your /etc/pam.d/login was mistakenly deleted, no one would be able to login!

A kinder configuration

Here's configuration that isn't quite so mean:

    auth	required	pam_unix.so 
    auth	required	pam_warn.so 
    account	required	pam_unix.so 
    account	required	pam_warn.so 
    password	required	pam_deny.so 
    password	required	pam_warn.so 
    session	required	pam_unix.so 
    session	required	pam_warn.so

This configuration will allow an unknown service to authenticate (via the pam_unix.so module), although it will not allow it to change the user's password. Although it allows authentication by unknown services, it logs a syslog warning whenever such a service attempts authentication.

Choosing a `/etc/pam.d/other`

I would strongly reccomend that you implement the first /etc/pam.d/other configuration unless you have a very good reason not to. It always a good idea to be 'secure by default'. If you ever do need to grant a new service authentication privileges, you can simply create a PAM configuration file for that service.

Disabling logins for user with null passwords

On most linux systems, there a number of "dummy" user accounts, used to assign privileges to certain system services like ftp, webservers, and mail gateways. Having these accounts allows your system to be more secure, because if these services are compromised, an attacker will only gain the limited privileges available to the dummy account, rather than the full privileges of a service running as root. However, allowing these dummy account login privileges is a security risk, as they usually have blank (null) passwords. The configuration option that enables null passwords is the "nullok" module-argument. You'll want remove this argument from any modules of 'auth' type for services that allow login. This is usually the login service, may also include services like rlogin and ssh. Hence, the following line in /etc/pam.d/login:

   auth		required	pam_unix.so	nullok

should be changed to:

   auth		required	pam_unix.so

Disable unused services

Looking at the files in /etc/pam.d/, you'll probably see configuration files for a number of programs you don't use and maybe even a few you've never heard of. Although allowing authentication to these services probably won't open any huge security holes, you're better off denying them authentication. The best way to disable PAM authentication for these programs is to rename these files. Not finding the file named after the service requesting authentication, PAM will fallback to the (hopefully) very secure /etc/pam.d/other. If you later find that you need one of these programs, you can simply rename the file to its original name and everything will work as it was intended.

Password-cracking tools

While password-cracking tools can be by attackers used to compromise a system, they can also be used by system administrators as proactive tool to ensure the strength of passwords on their system. The two most commonly used password-cracking tools are "crack" and "John the Ripper". Crack is probably included in your facorite distribution. John the Ripper can be obtained from http://www.false.com/security/john/index.html. Run the tools against your password database and you'll probably be surprised with what they come up with.

Additionally, there is a PAM module which utilizes the crack library to check the strength of a users password whenever it changed. When this module is installed, the user can only change their password to one which meets the minimum password strength.

Shadow and MD5 passwords

As was discussed in the first section of this document, Shadow and MD5 passwords can make your system more secure. During the installation procedure, most modern distributions will ask whether you want to install MD5 and/or Shadow passwords. Unless you have a good reason not to, you should enable these. The process of converting from non-shadowed/non-MD5 passwords is a complicated process, and is beyond the scope of this document. The Shadow Password HOWTO is outdated, but it might be of some help.