Unfortunately, if a token card is subjected to the preceding attack, the user now is exposed to a denial-of-service problem. An adversary can attempt to launch login sessions shorter than the allowed interval. The ACE/Server will disable a token card if this is detected, even if the card’s legitimate owner accounts for one of these login sessions.

Note that these attacks are really targeted at the protocol used between the client and the server. Although the SecurID card is backed by some expert security designers, it is inherently difficult to devise secure, distributed authentication protocols. Other protocol exploits can be found in the paper securid.ps found at www.secnet.com. Note that many of these problems have been fixed since the paper identified them. Still, it is interesting to read how complicated it can be to safely deploy strong authentication systems. As noted in the introductory chapters, a product will help you solve one class of problems, but by adding new protocols and security models, it also might open your system to attacks not previously possible.

Challenge-Response Authentication

To strengthen I&A further, the authenticating system displays a randomly chosen integer each time it shows the password prompt. Instead of merely keying in your password, you calculate some mathematical function using this challenge value and respond with the computed result. If the mathematical function used is cryptographically strong, you significantly improve I&A beyond the reusable password method. NT uses a challenge-response technique for authentication with domain controllers, although this authentication is not based on two separate factors by default.

Some commercial products, such as Digital Pathways (now part of Axent) combine challenge-response with hand-held token devices. The authentication software chooses a random value and sends it to the user as a challenge. A shared secret between the authentication server and the user is stored inside the token. The user keys the challenge into the token device that computes the response. To authenticate to the server, the user enters the response, which is verified at the authentication server.

You want to avoid some potholes with challenge-response systems. The challenge should come from a random source. Timestamps do not make good challenges because they come from a predictable sequence of numbers. Also, if the time values are not fine grained, you may be able to replay previous values or to trick one of the parties into computing responses in advance, which could be later used for a reflection attack. Finally, if authentication is mutual, each side of the protocol should use a different challenge, each preferably from different domains—such as the initiator always sends an even number, and the responder sends an odd number. This simple addition in complexity reduces the threat of replay attacks and reflection attacks (Kaufman, Perlman, and Speciner, 1995).

The Need for Intrusion Detection

Here is a recap of what is to be a recurring theme in the book. Your environment requires different software and hardware tools for solving security problems. Even as you add new techniques for reducing risks, you will find that enhancements you deploy also have their own weaknesses—either in implementation or in the way they might be configured. Therefore, you want to add IDS tools to detect and respond when other tools in your environment don’t work perfectly.

In this chapter, you have learned how the out-of-the-box configurations of UNIX and NT support I&A of users. Both operating systems rely on reusable passwords for authenticating users, although integration with other authentication servers is widely supported. Third-party authentication servers, such as Kerberos and Certificate Authorities, were introduced to show how I&A can be scaled for large environments. These discussions also highlighted the importance of correct protocols for proving identities in a distributed environment.

The two key recommendations for improving I&A security are to user either one-time passwords or strong two-factor authentication with token devices as a replacement for reusable passwords. Although the cost of deployment might be more, the added security is well worth the expense.

Finally, even though more secure authentication products, such as the Security Dynamics ACE/Server, can be added to your site, avenues of attack will still be open for a hacker. Some examples of attacks against the ACE/Server were described to emphasize this point. An authentication product will not deter, prevent, or detect many attacks. For example, an I&A product will not detect someone who maliciously deletes files or otherwise violates your security policy once logged in to the system! If you want to catch intruders who have hacked through your I&A system or insiders who are misusing corporate resources, IDSs are needed to detect and respond. Also, because systems like Kerberos introduce additional security models, you want to monitor their activities for intrusive behavior such as password guessing attacks.

Now that you understand how to improve the initial I&A step in computer interaction, it’s time to take a look at how access control decisions are made after you are connected. In the next chapter, you will learn about the underlying access control models of UNIX and NT, their weaknesses, and how you might overcome some of the problems.

Biometrics

Space does not permit a thorough coverage of the explosive field of biometrics. It seems that a new biometric product alliance is announced every day. A few years ago security product vendors rushed to alter their products to work with authentication devices from Security Dynamics or Digital Pathways. The same now can be said of biometric authentication. I&A systems based on fingerprints, voice, facial features, and keystroke patterns are available today. For more information, you can start by visiting the International Computer Security Association’s Web site and looking at www.ncsa.com/hotlinks/biometric.html.