Share your story
The central voice for Linux and Open Source security news
Home News Topics Advisories HOWTOs Features Newsletters About Register

Sign up!
EnGarde Community
What is the most important Linux security technology?
Linux Events
Linux User Groups
Link to Us
Security Center
Book Reviews
Security Dictionary
Security Tips
White Papers
Featured Blogs
All About Linux
DanWalsh LiveJournal
Latest Newsletters
Linux Security Week: March 30th, 2015
Linux Advisory Watch: March 27th, 2015
LinuxSecurity Newsletters
Choose Lists:
About our Newsletters
RSS Feeds
Get the LinuxSecurity news you want faster with RSS
Powered By

Securing User Authentication

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

4.1. 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, if 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 one which is gentler.

4.1.1. A paranoid configuration

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

    auth	required
    auth	required
    account	required
    account	required
    password	required
    password	required
    session	required
    session	required

With this configuration, whenever an unknown service attempts to access any of the four configuration types, PAM denies authentication (via the module) and then logs a syslog warning (via the 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!

4.1.2. A kinder configuration

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

    auth	required
    auth	required
    account	required
    account	required
    password	required
    password	required
    session	required
    session	required

This configuration will allow an unknown service to authenticate (via the 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.

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

4.2. 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 to remove this argument from any modules of 'auth' type for services that allow login. This is usually the login service, but it may also include services like rlogin and ssh. Hence, the following line in /etc/pam.d/login:

   auth		required	nullok

should be changed to:

   auth		required

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

4.4. Password-cracking tools

While password-cracking tools can be used by attackers 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 favorite distribution. John the Ripper can be obtained from 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.

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



Latest Features
Peter Smith Releases Linux Network Security Online
Securing a Linux Web Server
Password guessing with Medusa 2.0
Password guessing as an attack vector
Squid and Digest Authentication
Squid and Basic Authentication
Demystifying the Chinese Hacking Industry: Earning 6 Million a Night
Free Online security course (LearnSIA) - A Call for Help
What You Need to Know About Linux Rootkits
Review: A Practical Guide to Fedora and Red Hat Enterprise Linux - Fifth Edition
Yesterday's Edition
Feds Charged With Stealing Money During Silk Road Investigation
EFF questions US government's software flaw disclosure policy
Hotel Router Vulnerability A Reminder Of Untrusted WiFi Risks
Partner Sponsor

Community | HOWTOs | Blogs | Features | Book Reviews | Networking
 Security Projects |  Latest News |  Newsletters |  SELinux |  Privacy |  Home
 Hardening |   About Us |   Advertise |   Legal Notice |   RSS |   Guardian Digital
(c)Copyright 2015 Guardian Digital, Inc. All rights reserved.