PAP, CHAP and MSCHAPv2: Legacy Authentication Protocols and Where They Survive

Three authentication protocols from the dial-up era still appear in modern networks, usually inside a tunnel and occasionally not. Knowing what each provides — and specifically what MSCHAPv2 does not — is a recurring exam item and a real hardening decision.

PAP

Password Authentication Protocol sends the username and password in cleartext. That is the entire protocol. Anyone observing the exchange has the credentials.

It has one redeeming property: because the server receives the actual password, it can verify it against any credential store, including one holding only a modern salted hash. That is why PAP is still used as the inner method inside an encrypted tunnel — the tunnel provides the confidentiality, and PAP provides flexibility about where the password is checked.

Outside a tunnel it is indefensible, and a scenario describing PAP without encryption has exactly one correct answer.

CHAP

Challenge Handshake Authentication Protocol avoids sending the password. The server sends a random challenge, the client responds with a hash of the challenge combined with the password, and the server computes the same value and compares.

The password does not cross the network, and the challenge changes each time so a captured response cannot be replayed. CHAP also re-authenticates periodically during a session rather than only at the start.

Its limitation is on the server side: to compute the expected response, the server must know the password itself, which means storing it reversibly rather than as a modern hash. That is a significant weakness in the credential store, and it is the trade-off PAP inside a tunnel avoids.

CHAP is also one-way — the client proves itself to the server and not the reverse.

MSCHAPv2 and why it is broken

Microsoft's version adds mutual authentication, so the server proves knowledge of the password too, and it integrates with Windows credential storage using the NT hash rather than the plaintext password.

It is nevertheless considered cryptographically broken. The construction splits the key material into pieces small enough that a captured challenge-response pair can be reduced to a single DES key search, which is tractable — recovering the NT hash from a captured exchange is a bounded, purchasable computation rather than a hard problem.

And recovering the NT hash is sufficient, because the hash is the credential in Windows authentication — no cracking of the underlying password is required, as described under pass-the-hash.

The practical conclusion: MSCHAPv2 must never be exposed directly. It is acceptable only inside a properly validated encrypted tunnel, and its security then rests entirely on that tunnel.

Inside the tunnel

This is where these protocols actually live now. PEAP and EAP-TTLS establish a TLS tunnel authenticated by a server certificate, then run an inner authentication method inside it — commonly MSCHAPv2 for PEAP.

Which places the entire security of the arrangement on one client setting: whether the supplicant validates the server certificate and pins the expected authority and server name. A client that does not validate builds its tunnel to whatever answers, and hands the inner exchange straight to an attacker — the attack described under evil twin attacks on WPA2-Enterprise.

The stronger option removes the password entirely: EAP-TLS with mutual certificate authentication has no inner credential to capture, and its operational demands are covered under certificate lifecycle for device identity.

The same layering applies to VPNs. A legacy VPN using MSCHAPv2 without a validated tunnel is a documented weakness, and the fix is certificate-based authentication or a modern protocol rather than a longer password.

Where you still find them

PEAP-MSCHAPv2 remains extremely common in enterprise wireless because it authenticates against existing directory credentials with no certificate deployment to clients. Legacy VPN concentrators, point-to-point links, and older network device authentication all still offer these methods, often with the weakest one enabled by default.

The hardening action is to inventory which methods are permitted and disable the ones you do not need — a RADIUS server accepting MSCHAPv2 outside a tunnel will accept it from an attacker, whatever your intended configuration was. That inventory and enforcement belongs in the 802.1X policy rather than in each client.

Exam angles

Know PAP as cleartext, CHAP as challenge-response requiring reversibly stored passwords with periodic re-authentication, and MSCHAPv2 as adding mutual authentication while being cryptographically broken. Recognize that MSCHAPv2 is acceptable only inside a validated encrypted tunnel such as PEAP, and that server certificate validation on the client is what makes that tunnel meaningful. Identify EAP-TLS as the option with no password to capture.