What is the CHAP Protocol and Why Should You Care?

What CHAP Really Does - and Why Network Teams Still Care

The chap protocol — formally, the Challenge-Handshake Authentication Protocol — is a network authentication method that verifies identity without ever sending a password across the wire. Defined in RFC 1994, it was originally built for Point-to-Point Protocol (PPP) links and remains widely deployed in DSL, VPN, and RADIUS environments today.

Quick answer for those who need it fast:

Here's the core idea: instead of trusting a password sent over a connection, CHAP forces the authenticating party to prove they know the secret by solving a mathematical challenge. An attacker watching the traffic sees only a hash — useless without the original secret.

That's a meaningful security improvement over its predecessor, PAP, which simply sends credentials in cleartext. And while CHAP is far from cutting-edge by 2026 standards, it's embedded deeply enough in enterprise and ISP infrastructure that security teams still encounter it regularly — and need to understand its real-world trade-offs.

The sections below break down exactly how it works, where it fails, and what you should do about it.

Understanding the CHAP Protocol: Definition and Core Mechanics

At its heart, the chap protocol is a peer-to-peer authentication mechanism designed for use over Point-to-Point Protocol (PPP) links. Unlike modern web-based authentication that relies on heavy TLS certificates, CHAP was built to be lightweight and efficient, functioning at the Link Establishment Phase of a network connection.

The protocol relies on a shared secret—a piece of data known only to the authenticator (the server or router) and the peer (the client). Because the secret is never transmitted, an eavesdropper cannot simply "sniff" the credentials. Instead, the authenticator issues a nonce—a "number used once"—which serves as the basis for a cryptographic challenge.

The IETF standards specify that CHAP must be initiated by the authenticator as soon as the link is established. It can also be repeated at any time during the session to ensure that the client hasn't been swapped out mid-stream by an attacker. This periodic re-authentication is a hallmark of Challenge-Handshake Authentication Protocol implementations, providing a layer of session integrity that many newer protocols actually lack.

Packet Structure of the chap protocol

To understand how CHAP communicates, we have to look at its packet headers. Defined in RFC1994, a CHAP packet is encapsulated within the PPP Information field. The structure is rigid and efficient:

1. Code (1 octet): Identifies the type of CHAP packet.
   • 1 = Challenge
   • 2 = Response
   • 3 = Success
   • 4 = Failure
2. Identifier (1 octet): A sequence number used to match responses to specific challenges. If the authenticator sends a challenge with ID 0x05, the response must also use ID 0x05.
3. Length (2 octets): The total size of the packet, including the header.
4. Data (Variable): This field changes based on the Code. In a Challenge packet, it contains the "Value-Size" and the "Value" (the random nonce). In a Response packet, it contains the hash result and the "Name" (usually the username) of the peer.

Integrating the chap protocol with RADIUS and PPPoE

While CHAP started on serial links, it found a second life in broadband. If you use a DSL connection, your modem likely uses PPPoE (PPP over Ethernet), which frequently employs the chap protocol to validate your account with the ISP.

In enterprise environments, the Network Access Server (NAS) often acts as a middleman. It receives the CHAP challenge/response from the user and encapsulates it into a RADIUS (Remote Authentication Dial-In User Service) packet. Because RADIUS typically runs over UDP, the CHAP exchange provides a necessary layer of security for the credentials as they move from the gateway to the central authentication server. This transition from simple link-layer security to broader network architectures is a key part of Understanding Password Authentication Protocols From Pap To Modern Security.

The Three-Way Handshake: A Technical Deep Dive

The "handshake" in CHAP isn't just a polite greeting; it's a rigorous three-step verification process. Here is the technical breakdown of how a session is secured:

1. The Challenge: After the link is established, the authenticator generates a random value (the challenge) and sends it to the peer along with an ID.
2. The Response: The peer takes three ingredients: the ID, the shared secret (password), and the challenge value. It runs these through a one-way hash function—standard CHAP uses MD5. The formula looks like this: Response = MD5(ID + secret + challenge). The peer then sends this hash back to the authenticator.
3. The Verification: The authenticator, which also knows the secret, performs the exact same calculation on its end. If its calculated hash matches the response sent by the peer, it sends a Success packet. If they don't match, it sends a Failure and terminates the connection.

This process is inherently more secure than simple password checking because the "challenge" changes every single time. Even if an attacker captures the Response packet, they can't reuse it (a "replay attack") because the next challenge will require a completely different hash. This is why periodic re-authentication is so effective at preventing session hijacking—the server can "check in" every 15 minutes with a new challenge to make sure the original user is still there.

CHAP vs. PAP: Why Challenge-Response Supersedes Plaintext

In the early days of networking, the Password Authentication Protocol (PAP) was the standard. However, as security consciousness grew, the industry shifted toward CHAP.

The primary reason PAP is considered obsolete is its lack of encryption. As detailed in Password Authentication Protocol A Foundation For Understanding Modern Authentication, PAP is effectively a "bare minimum" protocol. If a technician or an attacker uses a tool like Wireshark on a PAP link, they can see the username and password in plain text.

The chap protocol solves this by using the challenge-response mechanism. It also mitigates "trial-and-error" or brute-force attacks on the wire, because the attacker never sees the password to begin with—only the result of a hash they can't easily reverse.

Security Vulnerabilities and the MS-CHAP Evolution

While CHAP is a massive leap over PAP, it isn't invincible. By May 2026, several of its core components have shown their age.

1. Offline Dictionary Attacks: If an attacker captures the challenge and the resulting response, they can take those values offline and run a dictionary attack. They guess a password, perform the MD5 hash with the captured challenge, and see if it matches the captured response. Because MD5 is incredibly fast to compute on modern GPUs, weak secrets can be cracked in seconds.

2. MD5 Weaknesses: Standard CHAP relies on MD5, which has been cryptographically broken for years. While a collision attack (creating two different inputs that produce the same hash) isn't a direct threat to the CHAP handshake, the general lack of "salt" and the speed of MD5 make it a liability.

3. The Microsoft Evolution (MS-CHAP): To address some of standard CHAP's limitations, Microsoft developed MS-CHAP and later MS-CHAPv2. As documented in [MS-CHAP]: Extensible Authentication Protocol Method for Microsoft Challenge Handshake Authentication Protocol (CHAP) | Microsoft Learn, MS-CHAPv2 introduced mutual authentication. In standard CHAP, the server authenticates the client, but the client has no way of knowing if the server is legitimate. MS-CHAPv2 requires both sides to prove they know the secret, preventing "Rogue NAS" or Man-in-the-Middle attacks.

4. Blast-RADIUS (CVE-2024-3596): A significant vulnerability disclosed in late 2024, known as Blast-RADIUS, highlighted risks in how RADIUS handles certain attributes. While this isn't a flaw in the chap protocol itself, it affects how CHAP is carried over RADIUS, allowing attackers to potentially spoof "Access-Accept" messages. This has forced many organizations to move toward RADIUS over TLS (RadSec) to protect the underlying CHAP exchange.

Implementation Best Practices for Modern Network Security

If you are tasked with managing or implementing the chap protocol in 2026, you cannot simply "set it and forget it." Modern security requires a more nuanced approach.

One of the most controversial aspects of CHAP is that it requires plaintext-equivalent storage. Because the server must calculate the hash itself to verify the client's response, it cannot store the password using a "salted and hashed" format like Argon2 or bcrypt. It must have access to the cleartext password or a reversible encryption of it. This makes the authentication database a high-value target; if the server is compromised, every user's password is exposed.

According to What is CHAP Protocol? | Definition, Types & Advantages!, best practices include:

• High Entropy Secrets: Since CHAP is vulnerable to offline dictionary attacks, secrets must be long, random, and complex.
• Out-of-Band Distribution: Never send CHAP secrets via email or unencrypted chat.
• Monitoring: Set aggressive thresholds for failed authentication attempts. A spike in CHAP failures is a classic indicator of a brute-force attempt.
• Layered Security: Whenever possible, wrap the CHAP exchange in a secure tunnel (like TLS or IPsec) to prevent attackers from capturing the challenge/response packets for offline cracking.

Configuration and Secret Management

On enterprise hardware like Cisco routers, configuring CHAP is straightforward but requires attention to detail regarding hostnames.

Router(config)# hostname Office-A
Office-A(config)# username Office-B password 0 MyStrongSecret123!
Office-A(config)# interface serial 0/0
Office-A(config-if)# encapsulation ppp
Office-A(config-if)# ppp authentication chap

Crucial Tip: In CHAP, the username configured on the local router must match the hostname of the remote router. If Office-A is connecting to Office-B, Office-A needs a username entry for "Office-B" with a password that matches exactly on both sides. This matching is case-sensitive and is a frequent source of "Authentication Failed" errors for junior sysadmins.

Frequently Asked Questions about CHAP

Why does CHAP require plaintext password storage on the server?

Unlike web logins where a server only needs to store a hash of your password, the chap protocol requires the server to actively participate in the cryptographic calculation. When the server receives a response, it must combine the password with the challenge it sent and run the MD5 algorithm. To do this, it needs the raw password. This is CHAP's "original sin" in security terms—it protects the password during transmission but makes the storage of that password much riskier.

How does CHAP provide protection against replay attacks?

CHAP uses a "nonce"—a random challenge value—that changes for every authentication attempt. Because the resulting hash is a product of this unique challenge, a captured hash from five minutes ago is mathematically useless for the current challenge. Even if an attacker records your successful login, they cannot "replay" that data to gain access later.

Is standard CHAP still considered secure in 2026?

In a vacuum, no. The reliance on MD5 and the requirement for plaintext password storage make it unsuitable for high-security applications. However, in the context of ISP links (PPPoE) or when encapsulated inside a secure TLS/IPsec tunnel, it remains a functional and widely supported "legacy" protocol. Most security professionals view it as a "better than nothing" option that should be phased out in favor of EAP-TLS (Extensible Authentication Protocol with Transport Layer Security) where possible.

Conclusion

The chap protocol is a fascinating relic of an era when network engineers first realized that sending passwords in cleartext was a recipe for disaster. While its cryptographic foundations (MD5) have crumbled over the decades, its core logic—the three-way challenge-response handshake—remains a fundamental concept in identity and access management.

For IT security professionals, the goal isn't necessarily to rip out every instance of CHAP, but to understand its limitations. Protect your authentication databases, use high-entropy secrets, and always look for opportunities to wrap legacy protocols in modern encryption.

To learn more about how authentication has evolved toward more secure, modern standards, check out our More info about passwordless authentication benefits guide. At Unlocked, we believe that understanding the history of protocols like CHAP is the best way to build a more secure future.