Skip to content

Page220

Secure Communications

Protecting data in motion is one of the most complex challenges we face. The Internet provides cheap global communication—with little or no built-in confidentiality, integrity, or availability. To secure our data, we often must do it ourselves; secure communications describes ways to accomplish that goal.

Authentication Protocols and Frameworks

An authentication protocol authenticates an identity claim over the network. Good security design assumes that a network eavesdropper may sniff all packets sent between the client and authentication server: the protocol should remain secure. As we will see shortly, PAP fails this test, but CHAP and EAP pass.

PAP and CHAP

PAP (Password Authentication Protocol) is a very weak authentication protocol. It sends the username and password in cleartext. An attacker who is able to sniff the authentication process can launch a simple replay attack, by replaying the username and password, using them to log in. PAP is insecure and should not be used.

CHAP (Challenge-Handshake Authentication Protocol) is a more secure authentication protocol that does not expose the cleartext password and is not susceptible to replay attacks. CHAP relies on a shared secret: the password. The password is securely created (such as during account enrollment) and stored on the CHAP server. Since both the user and the CHAP server share a secret (the plaintext password), they can use that secret to securely communicate.

To authenticate, the client first creates an initial (unauthenticated) connection via LCP (Link Control Protocol). The server then begins the three-way CHAP authentication process:

  1. Server sends a challenge, which is a small random string (also called a nonce).
  2. The user takes the challenge string and the password, uses a hash cipher such as MD5 to create a hash value, and sends that value back to the CHAP server as the response.
  3. The CHAP server also hashes the password and challenge, creating the expected response. It then compares the expected response with the response received from the user.

If the responses are identical, the user must have entered the appropriate password, and is authenticated. If they are different, the user entered the wrong password, and access is denied.

The CHAP server may re-authenticate by sending a new (and different) challenge. The challenges must be different each time; otherwise, an attacker could authenticate by replaying an older encrypted response.

A drawback of CHAP is that the server stores plaintext passwords of each client. An attacker who compromises a CHAP server may be able to steal all the passwords stored on it.