Security Dynamics ACE/Server

SDI provides a variety of token devices, the most familiar one in the form of a small electronic card. The token card displays an integer value to use as a one-time password. The value is not random but is instead computed as a mathematical function of the token’s unique ID and the current time. The ACE/Server knows the unique ID of each token as well. Before a token is distributed to the user, its time and unique ID are synchronized with the ACE/Server. At any given instant in time, the token card and the ACE/Server are locked onto the same one-time password value. The details of the mathematical computation used to generate the unpredictable integer values are not public. Like most time-synchronized systems, some amount of clock skew can be tolerated by the communicating systems. The skew value is configurable in the ACE/Server for each token device registered in its database.

In Figure 2.5 you see the basic SecurID card. A software token device was designed to operate the same way as a physical card but overcomes previous complaints about cards such as cost. Some tokens require that the terminal support a token reader device. For example, a token could be combined with a physical key that must first be used to unlock the token reader. Only after this step is complete can the user proceed to use the token card for authentication.

Figure 2.5  Standard card for a SDI token authentication device.

The ACE/Server contains a database of users, in which each user is associated with a personal identifier number (PIN) and individual token card. The PIN can be chosen by the user, and thus hidden from the administrator, or it can be assigned by the ACE/Server depending on site policy. PINs can be composed of numbers only or both numbers and letters. The PIN length is an important security factor, and SDI recommends a minimum length of six. Notice that the ACE/Server has introduced another repository for storing user information. This database must be kept in sync with the /etc/passwd file, for example, if SecurID cards are being used to replace reusable password logins in UNIX.

To authenticate to the ACE/Server the user enters both the PIN and the current number displayed on the token device. Together these values are called the passcode. This type of authentication is much stronger than using a single value such as a password.

What happens if an attacker manages to steal a PIN and somehow guess a token value, without possessing the token card? If the attacker tries several values before the guess succeeds, the ACE/Server detects the guessing attack and prompts for a second token value. Someone probably cannot guess two successive token values in sequence or the original token value in a single guess. The guessing threshold can be configured by the administrator. A separate threshold can be configured to limit the number of total failed passcodes allowed before a card is inactivated.

A stolen token card is useless without the user’s PIN. If the ACE/Server detects a sequence of events consisting of repeated incorrect PIN guesses with the appropriate token value, the server assumes that the token card has been stolen and ignores future authentication requests from that card. Someone who steals a token card and also uncovers the user’s PIN can impersonate the user. Because time synchronization between the server and the token cards is critical, the server will alert the administrator if its time is set back. A replay attack is possible with a previously used passcode if the server clock is set back. An adversary could shoulder surf to obtain an old token integer value. The PIN alone would be insufficient for a replay attack.

Attacks against ACE/Servers

Although SDI created a very strong authentication mechanism, successful attacks against the server have been documented. Two threats are faced by one-time password systems. The first problem is the man-in-the-middle attack in which an adversary sits on the network between the client and the authentication server. The attacker attempts to capture the packets for future replay or merely monitors packets in an effort to launch the second hack based on a race condition.

Because most authentication systems have defenses for replay attacks, the race condition is a greater threat. SecurID cards are configured to return or display a fixed-length value. This is true whether the token value is returned directly or the card is used for a challenge-response protocol. The default is 10-digit integers with no alphabetic characters. With enough effort, an attacker can discern the length for a given card that is the target of the hack. Early ACE/Servers were subject to the following weakness assuming that the length of the token value is D digits.

An opponent on system O first would detect that the login user has initiated an authentication session from the client to the ACE/Server. O then opens up D simultaneous authentication request connections with the server, too. The attacker watches each keystroke entered by the user as it is sent in a packet to the server. Assuming that the login user’s system is not buffering the token value and sending it in a single packet, each digit of the integer will be sent in a separate packet. As a digit is seen in a packet from the client to the server, O similarly packages up that digit and sends it to the server in each of its D connections. After the second to last digit (D-1) is sent by O, one each of the digits 0–9 will be sent by O on each of the D connections. This represents an attempt by the attacker to guess the appropriate last digit and send it to the server before the client. Network jamming techniques could be employed for slowing packet delivery from the client, so the attacker has a strong possibility of beating the client to the server. In addition, the attacker now has a 1-in-D chance of successfully authenticating to the server. Note that if the guessing threshold is set low enough, the token card will be disabled.

SDI modified the ACE/Server to deter this type of attack. For example, a token card can be used only in a single authentication dialogue. The same token cannot be used in simultaneous login attempts, although the same card can be reused within a short, configurable time interval. This fix is reasonable because it is unlikely that the token card can be in two distinct physical locations at once. Also, because network traffic between the clients and ACE/Server are encrypted and digitally signed, this attack is more difficult to carry out.