Two-Factor Authentication

With faster cracking programs available, passwords alone are no longer enough to keep naughty people off of your system. Use a USB device as a second check.

where $USER and $GROUP are the user and group that
own the other files in /var/log. Once the file has
been created and ownership has been set, simply change
the permissions on the file to reflect those of the
other files in /var/log by using this command:

chmod 0600 /var/log/pam_usb.log

More advanced users may want to configure a log
rotation schedule for the pam_usb.log or even change
the file to be append-only with chattr. Those
options are left as exercises for the reader to explore.

Now that the log file has been set up, we need to
back up the existing PAM configuration files. This is
an important step, so do not skip it. On most
systems, the PAM configuration files are stored in
/etc/pam.d. As root, make a backup copy with:

cp -rfp /etc/pam.d ~/pam.d/

For testing sake, we are working with the PAM
configuration for su, because it is the easiest
PAM-aware application to test. As a precautionary
method, you should keep a root shell open and
accessible so that if a mistake is
made in configuring pam_usb, you are able to rescue
yourself by overwriting the edited configuration files
with backups from your ~/pam.d. You also need
to know what filesystem is used on the USB drive(s)
you will be configuring. In an ideal world, we can
use mount to do the work for us, provided /mnt/usb
exists and your USB drive is on /dev/sda. Use:

mount /dev/sda1 /mnt/usb

and then run:

mount | grep usb

to see what filesystem is on the drive—the
filesystem is listed in parentheses at the end
of the line. Most USB drives use the vfat
filesystem and do not have more than one partition.
Thus, they are mountable with:

mount -t vfat /dev/sda1 /mnt/usb

Our first real step in configuring pam_usb is to alter
the PAM-aware applications' PAM configuration file—this step is required for each application you
want to use pam_usb to authenticate to. Because we're
working with su for testing purposes, focus only
on the /etc/pam.d/su file. Do not try to configure
every PAM-aware application in a single mass-edit
of your /etc/pam.d directory, or tears and sorrow
surely will be your lot. The files in /etc/pam.d/
correspond to the applications they configure, so if
you were to configure console logins or GNOME
Display Manager logins, you would be concerned with
/etc/pam.d/login and /etc/pam.d/gdm, respectively.
The naming pattern for PAM's configuration files
should be relatively self-evident. So, open
/etc/pam.d/su in your favorite text editor and add
the following line above the pam_unix line:

If you do not include the above line before the
pam_unix line, PAM never reaches the point of
authenticating against the USB device. Instead, it
is satisfied by the authentication that occurs
through pam_unix, and it drops out of the authentication
process.

A few options in the pam_usb
configuration that need further explanation: the
force_device option, the pam_usb mode, the filesystem
of the device and the log file we're going to use.

pam_usb is capable of autodetecting which
USB-attached device houses the authentication keys.
By not specifying the force_device directive, pam_usb
walks through all of the attached devices and looks for
keys matching the specified user name. This is helpful
if the machine has multiple USB devices that are
assigned device names according to the order in which
they were attached—the first device is /dev/sda,
the second is sdb and so on. If you specify the
force_device directive, you are not able to
authenticate unless your USB drive is assigned the
device name specified in the PAM configuration.

pam_usb supports three modes of operation: unique,
alternative and additional. With unique
mode, you can log in using your USB drive, but
if it's not present it isn't possible to log in.
This is achieved by commenting out pam_unix in
$PAMDIR/login and adding the configuration line above.
The alternative mode allows you to log in simply
by plugging in your USB key. If the key is not
present, the system prompts for a password. This is
accomplished by leaving pam_unix intact, adding
the above configuration line to the PAM configuration
file above the pam_unix entry and changing the auth
required bits of the line to read auth
sufficient. To achieve a true two-factor authentication, you need
to require both the user name/password pair and the
USB key, which is how the configuration above is set.

Andrea Luzzardi also points out an
alternative two-factor authentication that involves
encrypting the private key stored on the USB drive,
after which the key requires a password to be
decrypted and used for authentication. pam_usb is
capable of passing the password provided to PAM
through to decrypt the private key, thus accomplishing
two-factor authentication off of a single user name
and password pair. Furthermore, this is accomplished while not compromising any of the
security benefits of having two-factor authentication.
This method of authentication is contingent on using
the same password for the user account that was used to
encrypt the private key used by pam_usb. To encrypt
the private key used by pam_usb, simply use the usbadm
tool to create the cryptographic token:

As Linux continues to play an ever increasing role in corporate data centers and institutions, ensuring the integrity and protection of these systems must be a priority. With 60% of the world's websites and an increasing share of organization's mission-critical workloads running on Linux, failing to stop malware and other advanced threats on Linux can increasingly impact an organization's reputation and bottom line.

Most companies incorporate backup procedures for critical data, which can be restored quickly if a loss occurs. However, fewer companies are prepared for catastrophic system failures, in which they lose all data, the entire operating system, applications, settings, patches and more, reducing their system(s) to “bare metal.” After all, before data can be restored to a system, there must be a system to restore it to.

In this one hour webinar, learn how to enhance your existing backup strategies for better disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible bare-metal recovery solution for UNIX and Linux systems.