Challenge Handshake Authentication Protocol (CHAP) is a challenge-response identity authentication protocol. It depends on a combination of CHAP security credentials and a “shared secret” between the requestor (client) and the authenticator (server), and it does not expose a password. It requires both entities to prove their identity through a cryptographic exchange or a “three-way handshake”. When that is successful, authentication is complete.
Ongoing authentication requests from the server to the client continue on a regular basis after the initial handshake, which means the identifiers must change with every new authentication. This is one of the reasons why CHAP is more secure than Password Authentication Protocol (PAP).
Before the handshake process can begin, the client and the server must have each other’s credentials, including their shared secret, on file. Once a Point-to-Point Protocol (PPP) link is established, the client nudges the server by sending only their username (not the password) across the connection.
At this point, the server responds to the client’s username with a CHAP challenge packet and asks the client for a shared secret. This is part one of the three-way handshake.
The client provides the server with a valid, encrypted answer that contains the shared secret. This is the second part of the three-way handshake.
If the client’s answer matches what the server expected, the server authenticates the client. This is the third and final part of the three-way handshake.
Below is a more detailed look at what happens at each step.
As mentioned above, before a PPP link is established, the two entities must have each other’s CHAP credentials in their files. A CHAP credential consists of a CHAP username and a CHAP “secret.” A traditional password is not used or transmitted in CHAP.
With CHAP credentials in place, the initial PPP link can be activated. At this point, the client enters their username and password in the application or website. The username (not the password) is sent to the server to ask the server for a challenge packet.
SERVER: When the CHAP server receives the username from the client, it sends back a CHAP challenge packet that contains a random number and unique ID.
CLIENT: When the client receives the challenge, they must send back a calculation that contains the server’s random number and unique ID along with their own CHAP security credentials, which include the shared secret.
SERVER: If the client’s calculation matches the server’s calculation, the client is authenticated.
ONGOING AUTHENTICATION: After the initial authentication, while the client is still engaged in an online session, they’ll occasionally be re-authenticated by the server to make sure the connection remains safe and secure. Since these repeated challenges require a unique response from the client, it reduces the time of exposure to any single attack and lessens the threat of replay attacks.
PAP is more susceptible to cyberattacks than CHAP because it doesn’t have the built-in safeguards that CHAP has. Specifically, CHAP doesn’t transmit passwords, has an ongoing authentication mechanism, and uses an encrypted calculation to help each entity verify the identity of the other.
One of the reasons CHAP is so secure is that it uses a challenge-response mechanism that requires the client and server to share a secret calculation before the user can be authenticated. No password is ever transferred, which reduces the likelihood of password breaches. In addition, ongoing authentication offers an extra layer of security because the client has to provide a new calculation for the server each time.
Start Today
See how Ping can help you deliver secure employee and customer experiences in a rapidly evolving digital world.
Request a FREE Demo