Challenge Handshake Authentication Protocol

Key takeaways

• CHAP is defined by the IETF in RFC 1994 and is commonly negotiated within point-to-point protocol links during the PPP Link Control Protocol phase.
• The authenticator sends a challenge packet, the peer replies with a hash function output based on a shared secret, and the authenticator verifies the result.
• Because credentials are not transmitted as a username and password pair in cleartext, CHAP improves over Password Authentication Protocol.
• Password theft remains a leading driver of breaches, which keeps challenge-response designs relevant when deployed correctly.

What is Challenge Handshake Authentication Protocol (CHAP)?

CHAP is an authentication protocol that verifies a peer’s identity using a “three-way handshake” of challenge, response, and success or failure, typically inside a point-to-point protocol.

Challenge-Handshake Authentication Protocol (CHAP)  was standardized by the Internet Engineering Task Force to “periodically verify the identity of the peer using a three-way handshake.” It was originally designed for dial-up and WAN links using point-to-point protocol (PPP), but the same challenge-response pattern is still used in RADIUS, PPPoE, and various vendor implementations.

CHAP is a challenge-response method defined in IETF RFC 1994 for PPP links: the authenticator sends a random challenge, the peer returns a hash computed from the challenge, an identifier, and a shared secret, and the authenticator verifies before replying success or failure

How does Challenge Handshake Authentication Protocol work?

CHAP works by sending a random challenge packet from an authenticator, having a peer compute a response with a hash function and a shared secret, then validating that response. 

CHAP isn’t just a one-time login. It’s designed to maintain trust throughout the life of a PPP connection. Once the protocol is negotiated, CHAP introduces a repeatable handshake that keeps both sides confident the peer is who they claim to be.

Here’s the typical flow inside a PPP session:

• Negotiate method: During PPP LCP, both sides agree to use CHAP.
• Challenge: The authenticator sends a challenge packet that includes an identifier and a random value. 
• Response: The peer computes a one-way hash over the identifier, the shared secret, and the random challenge value, then returns the digest. Historically MD5 was specified in RFC 1994, though MD5 is now considered weak.
• Verify: The authenticator performs the same hash calculation and, if the results match, replies with Success, otherwise Failure.
• Periodic checks: CHAP may repeat challenges after link establishment to detect if a peer has changed.

Replay resistance comes from unpredictable challenges and the fact that only the digest crosses the wire, aligning with NIST’s guidance on replay attack resistance.

What is an example of Challenge Handshake Authentication Protocol?

Here’s a concrete walk-through of CHAP in action:

1. Link Control Protocol (LCP) complete: The PPP link comes up and both sides agree to use CHAP. 
2. Challenge sent: Router A sends a challenge packet with an identifier (ID) value and a 128-bit random number.
3. Response computed: Router B uses the ID, the shared secret (a password known to both sides), and the random challenge to create a hash (a one-way mathematical digest) and sends it back.
4. Success or failure: Router A performs the same calculation on its side and sends a success message if the results match. If the results don’t match, it sends Failure and the session won’t proceed.

This “challenge-response” deters simple replay attacks, since an intercepted response will not validate against a new challenge.

What are the pros and cons of Challenge Handshake Authentication Protocol?

CHAP reduces password exposure versus Password Authentication Protocol (PAP) and can detect peer changes, but CHAP’s classic MD5 variant is dated and requires both sides to store secrets in a form usable for hashing. 

While CHAP has clear strengths, its trade-offs become apparent when compared against both its predecessor and more modern alternatives. Understanding these advantages and limitations helps explain why CHAP still appears in some environments but has been replaced in others.

Pros

• No cleartext password on the wire: Only a digest is transmitted, which reduces risk versus sending a username and password pair directly.
• Replay resistance: New challenges make simple replays ineffective in compliant deployments.
• Periodic re-authentication: Challenges can be repeated during a session to re-validate the peer.

Cons

• Secret storage requirements: The server must hold a verifier equivalent to the real secret, which increases compromise impact.
• Legacy hashing: Classic CHAP specifies MD5, which modern guidance discourages in favor of stronger constructions or different methods.
• Scope limits: CHAP protects the authentication exchange, not the entire PPP data path, so additional controls are still needed.

What are the differences between CHAP and PAP?

CHAP uses a three-way handshake with a challenge packet and a hash function, while PAP sends a username and password in cleartext with a two-way handshake.

Where PAP is straightforward, but highly exposed, CHAP adds a layer of protection by never sending the actual password across the link.

Here are the key contrasts between CHAP and PAP:

• On-wire credentials: PAP transmits the password directly, while CHAP never does.
• Handshake pattern: PAP is request or response, then accept or reject, while CHAP is challenge, response, and success or failure with optional repeats.
• Replay and guessing risk: PAP is vulnerable to eavesdropping and replay attacks, whereas CHAP adds freshness via challenges, though both require strong secrets.
• Where it’s used today: Many stacks prefer MSCHAPv2 or EAP methods for WLAN and VPN, but PAP and CHAP still appear in PPP, PPPoE, and RADIUS integrations, especially for legacy gear.

Frontegg and CHAP

Frontegg supports modern authentication flows that build on the same challenge-response principles introduced by CHAP. Instead of passwords being sent directly, every request is validated through secure exchanges that resist replay attacks and credential theft.

This means product, security, and customer-facing teams get confidence that authentication events are verified in real time, without depending on engineering to configure or troubleshoot legacy protocols. 

With support for advanced policies, role-based access controls, and audit logs, Frontegg ensures authentication is both secure and easy to manage. Teams get the visibility they need to enforce compliance, reduce risk, and keep users protected.