In order to use any of the methods of authentication we've outlined
above, you need hardware or software to implement them. This section
discusses some of the commonly available hardware and software
authentication mechanisms that are at the heart of authentication
systems (in particular, it discusses those supported by the
TIS FWTK
, which is the most widely available
system). The most popular of the full-blown systems are discussed in
"Complete Authentication Systems" later in this chapter.

The list can be generated randomly, and a copy kept by the
user and the system.

The list (or, more likely, a specific entry from the list) can be
generated on demand by the user and validated by the system.

The problem with keeping a list on the system is that if the system is
compromised, so is the list, and the list could then be used for future
access. This is as bad as having someone snoop on a reusable password
while you use it.

The
TIS FWTK
supports an elegant, one-time
password solution called S/Key, originally designed by
Leslie Lamport and developed by Bellcore, which addresses this
problem. While it allows a system to reliably authenticate a user,
there is nothing on the system that compromises the user's password
if the system itself is compromised. The system has the ability to
validate a user's current response, but does not have the ability to
predict what that user's
next
response will be.

S/Key works by iteratively applying a cryptographically secure hash
algorithm, starting with some initial seed value. A cryptographically
secure hash algorithm is one that takes an arbitrary-sized input and
produces a much smaller output (something like a checksum) that has two
special properties:

The input cannot be regenerated from the output; thus, it's not
simply a compression or encryption algorithm.

The probability of two different inputs (particularly two different
inputs of the same size) producing the same output is vanishingly small.

S/Key uses such an algorithm, known as
MD
4.[2]
S/Key works by starting with a seed (which is either provided by the
user or generated randomly), and applying
MD
4
iteratively to get a sequence of keys. It applies
MD
4 to the seed to get the first key, applies
MD
4 to the first key to get the second key, applies
MD
4 to the second key to get the third key, and so
on. In order to validate a user, the system has to know some key (call
it key number
n
) in the sequence. The system
prompts the user for the previous key (key
n-
1),
applies
MD
4 to the user's answer (supposedly
key
n
-1), and checks to see if the result is the
key
n
that it knows. If the result is the key
n
, the user must have supplied the correct key
n
-1.

[2]
MD
4 stands for Message Digest function #4 and was
developed by Ron Rivest, the codeveloper of the
RSA
algorithm.

S/Key encodes each key into a series of short words, so they are
easier for a user to read and type, rather than simply generating a
random-looking jumble of characters.
Figure 10.1
shows how S/Key works.

Because
MD
4 is nonreversible (you can't determine
the input given the output), the system can't easily figure out what
key
n
-1 is, even though it knows key
n
. All the server can do is to verify that key
n
-1 (when presented by the user) is the key that
generates key
n
. This means that even if an
attacker can somehow obtain key
n
(for example,
by snooping on a user's login session), he won't be able to easily
figure out the next key (key
n-
1).

S/Key isn't absolutely invulnerable to attack. Several attacks are
possible:

Brute force attacks

Attackers could try a whole series of possibilities for key
n
-1 until they found one that
MD
4 translated to key
n
.
However, this type of attack is very unlikely to succeed. Because of
the size of the key space (the number of possible keys) and the
computation requirements of the
MD
4 algorithm, a
brute force approach of this kind is considered to be computationally
infeasible for all but the most serious and well-financed
attackers. (It would probably take a significant amount of
supercomputer time before they found the right key.)

Dictionary attacks

If the user provides the initial seed (rather than having the initial
seed be generated randomly), dictionary attacks are
possible. Attackers could guess at the seed in the same way that they
might guess at reusable passwords; they'd typically try things like
words from the dictionary, names, places, etc. To these words, they
would apply the
MD
4 algorithm an appropriate number
of times to see if it generates a key they've seen used.

Modified sniffing attacks

An attacker can run a packet sniffer and collect the beginning of an
S/Key password (all but the last few characters), and then try all the
possible combinations for the last characters, before the user
finishes. This relies on extremely delicate timing, but in Telnet
connections, user input is frequently set keystroke by keystroke as it
is generated. This creates a lag which is significant for a
computer. An attacker probably won't be able to try all possible
combinations, but may be able to try all possible combinations that
make English words.

There are two ways for users to use S/Key: either keys can be
generated on demand, or the user can be supplied with a printed list of
keys.

To generate S/Key keys on demand, the user needs a computer and a
program to generate them. That user will have to provide the seed and
the key number desired, and the program will iterate the MD4 algorithm
that many times to generate the key desired. The seed will have to be
either entered by the user or read from a file on the computer. If the
seed is entered by the user, the user would probably pick a seed the
same way he'd pick a password. Because users are notoriously poor
at picking passwords, this makes the system subject to dictionary
attacks, as we've described above. If the seed is read from a file, it
can be more random (and therefore less guessable) than something the
user would provide, but you have to worry about the risks - probably
low - of the computer or file being stolen.

The alternative way to use S/Key is to have the system generate and
print a list of keys, enough keys to last the user for a reasonable
period of time. In this case, the system randomly generates the initial
seed, thus protecting itself against dictionary attacks. The printout
should simply be a numbered list of keys, with no further identification
or explanation. It is possible that the list could be stolen from a
user, but you have to decide which you think is more likely: that the
list will be stolen (and that the thief will know what it is and what to
do with it), or that the user's session will be snooped on. If your
users are generating keys on demand, they're probably using a seed
that's subject to dictionary attack (otherwise, they would find it too
hard to remember the seed); if one of their sessions is snooped on,
their keys can be attacked.

We think that using a seed that's subject to dictionary attack is a
bigger risk than having a list of keys stolen, so we prefer using
printed lists of keys to using keys generated on demand.

Time-based password systems, such as those implemented by Security
Dynamics products, are a special type of one-time password. In such a
system, the password varies every minute or so, by an algorithm known to
the system and the user's authentication device. This device is
typically a small card, which Security Dynamics calls SecurID, with a
liquid crystal display readout for the current password. One possible
algorithm would be to encrypt the current time with a key known by the
system and programmed into the card. With such an algorithm, the system
would have to make allowances for clock drift (i.e., the clock in the
card running at a slightly different rate from that of the system
clock).

The Security Dynamics cards are supported by a wide variety of
commercial products. The
TIS FWTK
doesn't support
the cards directly, but it includes hooks to libraries that you can
license separately (at a significant cost) from Security Dynamics.

The Security Dynamics cards are not without their critics.
Various security professionals have expressed concern over Security
Dynamics' decision to use a secret, proprietary encryption algorithm,
rather than an algorithm, such as
DES
or
IDEA
, that has
been subjected to public scrutiny and analysis. Other people don't like
the fact that some versions of the
Security Dynamics cards combine "something you have" with "something you
know" by having the user send a traditional password over the Internet
along with the key displayed by the card; if an attacker monitors a
connection made using the card, and then steals the card itself, he
now
has everything he needs to break in. Finally, since the cards don't
have replaceable batteries, the entire card has to be replaced when the
batteries die (typically after about three years).

On the plus side, the keypad-less Security Dynamics cards are
user-friendly; it's hard to use something incorrectly when it has
exactly one button to press. If the button is accidentally pressed,
nothing horrible happens; it will wear the battery down faster, but it
won't make it impossible for you to authenticate. Also, because the
cards turn themselves off as soon as the displayed key
times out, pressing the button accidentally doesn't wear the
battery down that fast.

By contrast, cards that require
PIN
s are more
complex to use and usually disable themselves if the wrong buttons are
pressed too often. This means they can't be kept loose in a
purse or backpack without extra protection. Keypad-less Security
Dynamics cards are perfectly happy rattling around in a purse or
backpack. The three-year battery life is also arguably about the
expected lifetime of an authentication mechanism anyway; at the end of
three years, you may want to change the entire system, not just the
batteries.

Programming a Security Dynamics card, e.g., to set it for the system
with which it needs to synchronize, generally requires special
hardware.

Challenge-response systems are another way to support nonreusable
passwords.

The
TIS FWTK
supports the
SNK
-004 card from Digital Pathways for
challenge-response. When the user attempts to log in, the system
generates a random challenge. The user unlocks the
SNK
-004 card with a 4-digit
PIN
,
and then keys in the challenge. The card encrypts the challenge, using
the
DES
algorithm and a key programmed into the
memory of the card, and displays the encrypted result. The user sends
the result back to the system as his response to the challenge.

In the meantime, the system has encrypted the same challenge with the
key that is supposed to be in this user's card. If the system's result
is the same as the user's response, then the user has successfully
authenticated himself. All that has passed over the wire (and thus all
that could be snooped on) is the random challenge and the encrypted
result: not the user's
PIN
(used to unlock the
SNK
-004 card) or the key (programmed into the
memory of the
SNK
-004 card, and known by the
system).

The
TIS FWTK
includes, for free, almost everything
you need to support the
SNK
-004 cards; the
only exception is a
DES
library, several of which
are available for free on the Internet.

Digital Pathways also sells programs for Macintosh,
MS-DOS
, and Microsoft Windows that emulate the
SNK
-004 card in software. Users who carry portable
computers they log in from (or who always connect from the same
desktop computer) will probably find it more convenient to use that
software than to carry the separate
SNK
-004 card.

SNK
-004 cards can be configured to disable
themselves if the wrong
PIN
is entered more than
five consecutive times. Unfortunately, accidentally turning on the card
counts as a "wrong
PIN
" attempt, so the
card can end up disabling itself if it's floating around loose in your
luggage and something keeps pressing the "On" button; many
people carry them in hard cases to prevent accidental activations.
(Digital Pathways doesn't provide a hard case, but an 8mm tape case
makes a good improvised one.) Digital Pathways reportedly has a new
card to replace the
SNK
-004 that addresses this
problem and may have other new features.

The
SNK
-004 can be programmed from its own keyboard
with no special hardware, but anybody who doesn't do it every day will
need to step through the procedure from the manual. (Warning: The
SNK
-004 programming procedure makes
VCR
programming look intuitive by contrast!)
Programming hardware is available, and is probably a useful investment
if you need to initialize more than a handful of the units.