PAP uses a two-way handshake to authenticate client sessions, while CHAP uses a three-way handshake. Both authentication processes are common, but one is more secure.
PAP works like a standard login procedure. The remote system authenticates itself by using a static username and password combination. The password can pass through an established encrypted tunnel for additional security, but PAP is subject to numerous attacks. Because the information is static, it is vulnerable to password guessing and snooping.
CHAP takes a more sophisticated and secure approach to authentication. It creates a unique challenge phrase for each authentication by generating a random string. This challenge phrase is combined with device hostnames using one-way hash functions. With this process, CHAP can authenticate in a way that static secret information isn’t sent over the wire.
Let’s dive deeper into the differences between PAP and CHAP and how they can work together.
What is PAP?
Of the two Point-to-Point Protocol (PPP) authentication methods, PAP is older. It was standardized in 1992 by way of IETF Request for Comments 1334. PAP is a client-server, password-based authentication protocol. Authentication occurs only one time at the beginning of a session establishment process.
PAP uses a two-way handshake process for authentication using the following steps.
Step 1. Client sends username and password to server.
The client wishing to establish a PPP session with a server sends a username and password combination to the server. This is performed through an authentication-request packet.
Step 2. Server accepts credentials and verifies.
If the server is listening to authentication requests, it will accept the username and password credentials and verify that they match.
If the credentials are sent correctly, the server will send an authentication-ack response packet to the client. The server will then establish the PPP session between the client and server.
If the credentials are sent incorrectly, the server will send an authentication-nak response packet to the client. The server will not establish a response based on the negative acknowledgement.
PAP is a simple authentication mechanism and easy to implement, but it has serious drawbacks to its use in real-world environments. The biggest drawback is PAP sends static usernames and passwords from clients to servers in plain text. If bad actors intercepted this communication, using tools like a packet sniffer, they could authenticate and establish a PPP session on the client’s behalf.
It’s possible to send PAP authentication requests through existing encrypted tunnels. But, if other authentication options are available, such as CHAP, teams should use an alternative method.
What is CHAP?
CHAP uses a three-way handshake process to protect the authentication password from bad actors. It works as follows.
Step 1. After the link is established, the authenticator sends an authentication challenge.
The network access server performs a hostname lookup on the client and initiates the CHAP authentication by sending an “ask challenge” to the remote user. This challenge includes a randomly generated challenge string.
Step 2. Client performs hostname lookup.
The client uses the password that both the client and server know to create an encrypted one-way hash based on the challenge string.
Step 3. Server decrypts hash and verifies.
The server will decrypt the hash and verify that it matches the initial challenge string. If the strings match, the server responds with an authentication-success packet. If the strings do not match, the server sends an authentication-failure message response, and the session is terminated.
What are the differences between PAP vs. CHAP?
CHAP came along in 1996 largely as a response to the authentication weaknesses inherent in PAP. Instead of a two-way handshake, CHAP uses a three-way handshake and doesn’t send the password across the network. CHAP uses an encrypted hash for which both the client and server know the shared secret key. This extra step helps eliminate the security weaknesses found in PAP.
Another difference is CHAP can be set up to do repeated midsession authentications. This is useful for certain PPP sessions that leave a port open even though the remote device has disconnected. In that case, someone else could pick up the connection midsession by establishing physical connectivity.
How can PAP and CHAP work together?
PAP and CHAP can’t work together per se. But protocols that use either PAP or CHAP can interact with both authentication methods, if desired.
For example, PPP can use either PAP or CHAP for authentication. So, administrators could configure the communications protocol to try to authenticate via CHAP’s secure three-way handshake first and then fall back to the less secure, two-way authentication process found in PAP.