ADMIN

Nuts and Bolts
PAM and Hardware
the stolen number will not match the
number on the system.
Gentoo and Debian Linux offer prebuilt
packages of this PAM library. In
both cases, you can use the package
manager to install, as described for
pam_thinkfinger. Users on any other
Linux distribution can download the
current source code archive [3] and
run make; make install to compile
the required files and install them on
the local system. Then you need to
connect any USB device – it can be
a cellphone with an SD card if you
like – and store its properties in the
/etc/pamusb.conf file. The command
for this is
pamusb‐conf ‐‐add‐device USB‐device‐name
(Figure 6). The command
pamusb‐conf ‐‐add‐user user
lets you add more users to the configuration
and generates a matching
random number. The number for
each user is stored both on the USB
device and on the system. Also, the
tool adds each user to the XML-based
/etc/pamusb.conf configuration file.
You can use the file to define actions
for each user; these actions will
run when the USB is plugged in or
unplugged. For example, the entry
in Listing 1 of the configuration file
Listing 1: Configuration File for pam_usb
01
02
03 /dev/sdb1
04
05 gnome‐screensaver‐command
‐‐lock
06 gnome‐screensaver‐command
‐‐deactivate
07
Listing 2: USB Device-Based Authentication
[tscherf@tiffy ~]$ id ‐u
500
[tscherf@tiffy ~]$ su ‐
* pam_usb v0.4.2
* Authentication request for user "root" (su‐l)
* Device "/dev/sdb1" is connected (good).
* Performing one time pad verification...
* Verification match, updating one time pads...
* Access granted.
[root@tiffy ~]# id ‐u
0
automatically blocks the screen if the
USB device is unplugged: Then You
need to add the pam_usb PAM library
to the corresponding PAM configuration
file, /etc/pam.d/system‐auth or
/etc/pam.d/common‐auth. If you use
the sufficient control flag, users can
log in to the system by plugging in
the USB device, assuming the random
number for the user matches on both
devices (Listing 2).
To enhance security, you can replace
the sufficient control flag with required.
This setting first looks for the
USB device, but even if the device is
identified correctly, PAM still prompts
the user for a password in the next
stage of the login process. Both of
these tests have to complete successfully
for the user to log in.
All of the hardware-based login
methods I have looked at thus far
are easily set up, but they all have
vulnerabilities, and it is easy to fake
fingerprints. Also, USB sticks can be
stolen, thereby putting an end to any
security they offered. If you take your
security seriously, you will probably
want to use two-factor authentication.
This method inevitably involves using
chip cards with readers or USB tokens
with one-time passwords and PINs.
Yubikey
A small company from Sweden,
Yubico [4], recently started selling
Yubikeys (Figure 7), which are small
USB tokens that emulate a regular
USB keyboard. The key has a button
on top which, when pressed, tells the
token to send a one-time password
(OTP) to the active application, such
as a login prompt on an SSH server
or the login window of a web service.
The OTP is verified in real time by a
Yubico authentication server. Because
the software was released under an
open source license, you could theoretically
set up your own authentication
server on your LAN. This would
remove the need for an Internet connection.
The way the token works is quite
simple. In contrast to popular RSA tokens,
Yubikey doesn’t need a battery
because the OTP is not generated on
the fly; instead, one-time passwords
are defined in advance. The passwords
are stored on the token and
in a database on the authentication
server.
When you press the Yubikey button,
the key sends one of these OTPs to
the active application, which then
uses an API to access the server and
verify the password. If this fails (Unknown
Key) or if the password has
already been used (Replayed Key), an
error message is output and the login
fails. If the server identifies the key
as valid, it sets usage‐count to 1 and
the user is authenticated. The user
cannot login with this key anymore
times.
Because of the simple API, more
and more applications are relying
on authentication against the Yubico
server. One example is the plugin for
the popular WordPress blog, which
allows users with a Yubikey to log in
to the blog. A project from Google’s
Summer of Code produced a PAM
module that supports logging in to an
SSH server [5].
Instead of typing your user password
at the login prompt, you simply press
the button on the Yubikey to send a
44-character, modhex-encoded password
string to the SSH server. The
server then verifies the string by querying
the Yubico server. The first 12
characters uniquely identify the user
on the Yubikey server; the remaining
32 characters represent the one-time
password.
You can define a central file on the
SSH server to specify users permitted
to log in by producing a Yubikey. To
do so, first create a /etc/yubikey‐users.txt
file with a username, a colon
separator, and the matching Yubikey
ID (i.e., the first 12 characters of the
user’s OTP) for each user. Alternatively,
users can create a file (~/.
yubico/authorized_yubikeys) with
the same information in their home
directory.
You need to configure PAM to verify
the OTP against the Yubico server. To
do so, add a line for the Yubikey to
your /etc/pam.d/sshd file (Listing 3).
The configuration shown in Listing
3 runs this authentication in addition
82 Admin 01 www.admin-magazine.com