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 MD4. S/Key works by starting with a seed (which is either provided by the user or generated randomly), and applying MD4 iteratively to get a sequence of keys. It applies MD4 to the seed to get the first key, applies MD4 to the first key to get the second key, applies MD4 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 MD4 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.
 MD4 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 MD4 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:
Attackers could try a whole series of possibilities for key n-1 until they found one that MD4 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 MD4 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.)
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 MD4 algorithm an appropriate number of times to see if it generates a key they've seen used.
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.
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 PINs 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.
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).
Figure 10.2 shows how this challenge-response works.
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.