By Kurt Seifried [email protected]
Introduction
Authentication is typically one of the two main lines of defense that systems
and networks rely upon, so ensuring that your authentication subsystems are
implemented correctly is important. The majority of Linux systems rely on
usernames and passwords, while support for tokens, smartcards and other
authentication systems are available they are still relatively rare. On top of
this sits PAM, as far as I know all major vendors use PAM by default, so
understanding how PAM works and using it correctly is very important.
PAM
"Pluggable Authentication Modules for Linux is a suite of shared libraries
that enable the local system administrator to choose how applications
authenticate users." Straight from the PAM documentation, I don't think I could
have said it any better. But what does this actually mean? For example; take the
program login, when a user connects to a tty (via a serial port or over the
network) a program answers the call (getty for serial lines, telnet or SSH for
network connections) and starts up a login program, login then typically
requests a username, followed by a password, which it checks against the
/etc/passwd file. This is all fine and dandy until you have a spiffy new digital
card authentication system and want to use it. Well you will have to recompile
login (and any other apps that will do authentication via the new method) so
they support the new system. As you can imagine this is quite laborious and
prone to errors.
PAM introduces a layer of middleware between the application and the actual
authentication mechanism. Once a program is PAM'ified, any authentication
methods PAM supports will be usable by the program. In addition to this PA can
handle account, and session data which is something normal authentication
mechanisms don't do very well. For example using PAM you can easily disallow
login access by normal users between 6pm and 6am, and when they do login you can
have them authenticate via a retinal scanner. By default Red Hat systems are PAM
aware, and newer versions of Debian are as well (see bellow for a table of
PAMified systems). Thus on a system with PAM support all I have to do to
implement shadow passwords is convert the password and group files; and possibly
add one or two lines to some PAM config files (if they weren't already added).
Essentially, PAM gives you a great deal of flexibility when handling user
authentication, and will support other features in the future such as digital
signatures with the only requirement being a PAM module or two to handle it.
This kind of flexibility will be required if Linux is to be an enterprise-class
operating system. Distributions that do not ship as "PAM-aware" can be made so
but it requires a lot of effort (you must recompile all your programs with PAM
support, install PAM, etc), it is probably easier to switch straight to a
PAM'ified distribution if this will be a requirement. PAM usually comes with
complete documentation, and if you are looking for a good overview you go https://www.sun.com/software/solaris/pam/.
Other benefits of a PAM aware system is that you can now make use of an NT
domain to do your user authentication, meaning you can tie Linux workstations
into an existing Microsoft based network without having to say buy NIS / NIS+
for NT and go through the hassle of installing that. As far as I know all modern
Linux distributions have PAM support and default to it.
PAM Cryptocard Module
A PAM cryptocard module is available https://projects.jdimedia.nl/index.phtml?ID=crypto&L=&BROW=1&W=1260&H=886.
Cryptocards are excellent for securing interactive logins since they do not
require any special equipment on the client end, thus you can log in from a
cybercafe for example with no fear of your password being stolen (since it
changes each time you log in). Unfortunately Cryptocards tend to be expensive
and require some user training, I would advise them primarily for installations
with a higher need of security then "normal" or for infrastructure related
servers and equipment (i.e. Authentication servers).
Pam Smart Card Module
Smartcards can be used to sign and encrypt email as well as providing login
services. The primary problem with smartcards however is that the client station
needs a compatible card reader, the chances of finding these on a system outside
of your office are slim indeed. A module to provide PAM support for smartcards
is available https://www.linuxnet.com/apps.html.
Pam module for SMB
SMB (Server Message Block) is incredibly popular protocol for the simple
reason Microsoft has choosen to use it as their primary protocol for Windows 9x
and NT (it is also supported in 2000). Many sites have existing NT
infrastructures, adding Linux servers that require their own authentications
infrastructure can be quite troublesome. Fortunately you can authenticate on
Linux machines against SMB servers, packages are available https://rpmfind.net/linux/rpm2html/search.php?query=pam_smb and
the primary site is https://www.csn.ul.ie/~airlied/pam_smb/. You can also install
SAMBA on the machine and use this to authenticate but for workstations the PAM
module is much more appropriate.
Pam module for LDAP
https://www.padl.com/OSS/pam_ldap.html
Authentication services
Authentication services such as NIS and Kerberos are covered in the network
servers section of the LASG <a
href="../network-servers/authentication/">here. Generally speaking they are
easy to implement client side on modern Linux distributions, during install you
are often given the choice of Kerberos, LDAP or NIS+ passwords and their related
settings. Setting up the servers however is another matter.
Passwords
In all UNIX-like operating systems there are several constants, and one of
them is the file /etc/passwd and how it works. For user authentication to work
properly you need (minimally) some sort of file(s) with UID to username
mappings, GID to groupname mappings, passwords for the users, and other misc.
info. The problem with this is that everyone needs access to the passwd file,
every time you do an ls it gets checked, so how do you store all those passwords
safely, yet keep them world readable? For many years the solution has been quite
simple and effective, simply hash the passwords, and store the hash, when a user
needs to authenticate take the password they enter it, hash it, and if it
matches then it was obviously the same password. The problem with this is that
computing power has grown enormously and I can now take a copy of your passwd
file, and try to brute force it open in a reasonable amount of time (assuming
you use a poor hash system, or weak passwords).
Use a better hash
Using a hash such as MD5 or blowfish significantly increases the amount of
computing power needed to execute a brute force attack, but there are two large
problems with switching from the traditional crypt hash. The first is
compatibility, if you use NIS or NIS+ with systems such as Solaris using a
different hash then crypt will break authentication, obviously a problem. The
other problem is that no matter how strong a hash you use poor passwords (such
as the username or "dog") will still be easily discovered. If possible you
should use a better hash, but if this is not possible then there is another
solution.
Use shadow passwords
User account data is stored in /etc/passwd traditionally, but the actual
password hashes and related data (password expiry, etc.) is stored in
/etc/shadow, a file only readable by root. Programs that need to check a
password can either run as root or use a setuid or setgid wrapper program (like
PAM provides) to check the password, the only way to get access to /etc/shadow
requires root privileges. There have been problems in past with setuid programs
that read /etc/shadow leaking information, however these are relatively rare
(and you are no worse off then storing passwords in a world readable location).
Several OS's take the first solution, Linux has implemented the second for
quite a while now. Because most vendors rely on PAM for authentication services,
implementing a new authentication scheme is relatively simple, all you need to
do it add a PAM module that understands the new authentication scheme and edit
the PAM config file for whichever program (say login) uses it. Now for an
attacker to look at the hashed passwords they must go to quite a bit more effort
then simply copying the /etc/passwd file.
Cracking passwords
In Linux the passwords are stored in a hashed format, however this does not
make them irretrievable, chances are you cannot reverse engineer the password
from the resulting hash, however you can hash a list of words and compare them.
If the results match then you have found the password (the chances of a
different word hashing to the same value as another are slim), this is why good
passwords are critical, and dictionary based words are a terrible idea. Even
with a shadow passwords file the passwords are still accessible by the root
user, and if you have improperly written scripts or programs that run as root
(say a www based CGI script) the password file may be retrieved by attackers.
The majority of current password cracking software also allows running on
multiple hosts in parallel to speed things up.
Most modern Linux distributions use MD5 hashed passwords at a minimum
(notable exceptions are SuSE and Debian which default to crypt for backwards
compatibility with NIS and the like). In any event password crackers will
usually catch poor passwords or dictionary based passwords quickly. As well on
modern systems passwords are protected in shadow password files, if an attacker
has access to this file chances are they have sufficient privilege to do other
things to compromise the system.
VCU
VCU (Velocity Cracking Utilities) is a windows based programs to aid in
cracking passwords, VCU attempts to make the cracking of passwords a simple
task for computer users of any experience level. You can download it https://packetstormsecurity.org/groups/wiltered_fire/NEW/vcu/
Password storage
This is something many people don't think about much. How can you securely
store passwords? The most obvious method is to memorize them, this however has
it's drawbacks, if you administer 30 different sites you generally want to have
30 different passwords, and a good password is 8+ characters in length and
generally not the easiest thing to remember. This leads to many people using the
same passwords on several systems (come on, admit it). One of the easiest
methods is to write passwords down. This is usually a BIG NO-NO; you'd be
surprised what people find lying around, and what they find if they are looking
for it. A better option is to store passwords in an encrypted format, usually
electronically on your computer or palm pilot, this way you only have to
remember one password to unlock the rest which you can then use. Something as
simple as PGP or GnuPG can be used to accomplish this. If you can afford it
using authentication tokens or smartcards are a good way to reduce the number of
passwords you must memorize.
Many of these programs have been found to contain flaws, I advise using them
with caution.
Strip
Strip is a palm pilot program for storing passwords securely and can also be
used to generate passwords. It is GNU licensed and available https://www.zetetic.net/products.html. The generation function
is flawed and should not be used.
