Challenge Handshake Authentication Protocol

From Hill2dot0
(Redirected from CHAP)
Jump to: navigation, search

The Challenge Handshake Authentication Protocol (CHAP) provides password protection, but ensures that the password is never sent on the line in such a way that an eavesdropper can obtain it. CHAP works as shown on the accompanying diagram. Before describing the diagram, however, it is worth noting that CHAP uses encryption to protect the password. CHAP typically uses a scheme called Message Digest 5 (MD5). Described in RFC 1321, MD5 is a one-way encryption algorithm that accepts an arbitrary length input and produces a 128 bit output, called the hash value. The important part to note is that the original input string is unobtainable by an attacker knowing only the hash value.

In the CHAP scenario, a user (i.e., gkessler) dials in to a remote access server. Once the connection has been established, the CHAP procedures are initiated. First, the user sends the user name (in plaintext; it’s no secret anyway) to the CHAP server. The server responds back to the user by sending a random string of characters. The server then uses the random string and user’s password (stored in a local database) and applies a hashing function to calculate the hash value of the string.

The user, meanwhile, uses the string from the server and the password to also calculate the hash value. The client then sends the calculated hash back to the server. The server compares the hash value received from the client to the hash that it calculated to determine if the client really knows the password; if so, the user is logged in.

Note that the use of a random string is critical to CHAP’s successful operation. If the same string were used over and over, the password would still never be transmitted as plaintext—but an eavesdropper could obtain the hash value and use it in a later attack.

Two more points are worth noting.

  1. CHAP only authenticates the client. The client assumes that it has connected to the correct server. The client has some reason to assume that this is the correct server, since only the correct server would be able to find a matching password for this user name. However, CHAP does not provide mutual authentication.
  1. CHAP is susceptible to a person-in-the-middle attack. Suppose an eavesdropper were to insert themselves between the client and the server. The eavesdropper would pass all of the messages shown on the visual to the intended receiver (either client or server), but then kick the “real” client off as soon as the login was successful. Most users would merely think that the line had dropped, would then dial-in again, and the incident would not likely be reported. To prevent this from occurring, the authenticator sends a new challenge to the peer at random intervals. Presumably, spoofed connections will not be able to provide the correct shared secret. Thus, while an attacker could intercept a connection, he would not be able to stay connected long.

See Also


<mp3></mp3> | PAP and CHAP