Understanding MSCHAP Vulnerabilities on Your Network

In 2013, Microsoft released a report of a known security vulnerability present within PEAP-MSCHAPv2 Wi-Fi authentication. This authentication protocol is a widely supported standard and can be exploited using this vulnerability to gain user login information from devices which are not properly configured to connect only to trusted RADIUS servers.

Organizations can avoid this security issue by configuring devices for Server Certificate Validation or replacing the PEAP-MSCHAPv2 protocol with EAP-TLS.

What Is MSCHAP?

MSCHAP (Microsoft Challenge-Handshake Authentication Protocol) is Microsoft’s version of the Challenge-Handshake Authentication Protocol (CHAP), a password-based method that proves a user knows a password without sending the password itself over the link. It exists in two versions: MS-CHAPv1, defined in RFC 2433, and MS-CHAPv2, defined in RFC 2759.

MSCHAPv2 is the version in common use today. It adds mutual authentication, meaning the client also verifies the server, and it derives its challenge response from the NT hash of the user’s password, which is the MD4 hash of that password. The plaintext password is never transmitted. MSCHAP is most often seen as the inner authentication method inside PEAP for Wi-Fi and as a VPN authentication option.

PEAP-MSCHAPv2 belongs to the family of Extensible Authentication Protocol (EAP) methods used in WPA2-Enterprise Wi-Fi.

Why MSCHAP Is Vulnerable

The MSCHAP vulnerability comes from the cryptography underneath it. MSCHAPv2 uses the NT hash. This hash is an MD4 hash, and MD4 has been considered cryptographically broken for years. In 2012, security researchers Moxie Marlinspike and David Hulton presented work at DEFCON (released as the chapcrack tool with the CloudCracker service) showing that a captured MSCHAPv2 handshake can be compromised by breaking a single DES (56-bit) key, regardless of how strong the underlying password is.

PEAP is meant to mitigate this by wrapping the MSCHAPv2 exchange inside an encrypted TLS tunnel so it cannot be read over the air. That protection holds only if the client validates the RADIUS server’s certificate. When a device skips server certificate validation, an attacker running an evil twin or rogue access point can terminate the TLS tunnel itself, capture the inner MSCHAPv2 handshake, and then crack it offline. This means misconfiguration, rather than weak cryptography, is the primary issue.

The Security Risks of PEAP-MSCHAPv2 Device Misconfiguration

Here’s a potential vulnerable scenario: An attacker can imitate a trusted access point from their own laptop, for instance on a college campus. A student whose device has not been configured properly for the school’s legitimate SSID will connect to the nearby imitation SSID automatically, and will attempt to auto-authenticate with the attacker’s spoofed network. In doing so it sends encrypted packets containing the user’s login information to the attacker’s computer. A well-documented weakness in PEAP-MSCHAPv2’s encryption method allows the attacker to easily decrypt the packets, thereby allowing the attacker to easily acquire the user’s login credentials.

Vulnerabilities like the one described above are exactly why industry titans like Microsoft have recommended moving away from PEAP-MSCHAPv2. Microsoft’s official recommendation is as follows: “If you are using Wi-Fi and VPN endpoints that are based on MSCHAPv2, they are subject to … attacks, Microsoft recommends that organizations move to certificate-based authentication… like EAP-TLS.”

Differences Between MSCHAP and MSCHAPv2

The original MSCHAP (MS-CHAPv1) and MSCHAPv2 are both challenge-response password protocols, but MSCHAPv2 added mutual authentication and other fixes. The table below summarizes the differences. Neither version is considered safe for modern networks without a TLS tunnel and validated server certificates.

	MS-CHAPv1	MS-CHAPv2
Defining RFC	RFC 2433	RFC 2759
Authentication	One-way (server authenticates client)	Mutual (client also verifies server)
Password handling	NT hash (MD4); LM hash also used	NT hash (MD4) only; plaintext never sent
Known weakness	Weak hashing; broken	Reduces to a single DES key when handshake is captured (2012)

RADIUS Server Certificate Validation

Microsoft provides recommendations to help users secure their devices, and a vital part of the defense relies on the use of server certificate validation. This protocol is active when a user attempts to connect to the network. The authenticating RADIUS server has an identified and trusted certificate issued by a public certificate authority or an IT department in the form of a private certificate. Server certificate validation prevents over-the-air credential theft by verifying the RADIUS server possesses the trusted certificate, which confirms that the network is legitimate and will connect the device to the network.

Failure to verify the server certificate leaves users and devices susceptible to Active Directory or LDAP credential theft via a simple man-in-the-middle attack.

A detailed explanation from Vivek Ramachandran, a world-renowned security researcher, can be seen here:

Enforce Server Certificate Validation on Every Device

The process to set up server certificate validation is device-specific and difficult for users to correctly configure on their own. Manual configuration of personal devices presents serious security risks because users tend to skip server certificate validation and accidentally trust rogue networks.

Auto-configuration tools such as the JoinNow platform automate this process for the user and make certain that the device is configured correctly for the secure network. JoinNow correctly configures the device to check for specified certificates to verify that the device is connected to the trusted network. Certificate prompts are imperative in today’s environments when considering how often they are ignored by users, confusing to interpret, and cause serious security issues and help desk tickets if not configured properly.

EAP-TLS Factors Device Trust Into Network Security

We’ve explained already why organizations should move away from vulnerable PEAP-MSCHAPv2. One question remains to be answered, though: what’s the alternative?

The answer, as we touched on briefly with Microsoft’s quote, is the EAP-TLS authentication protocol. This protocol allows organizations to replace credentials with certificates for enhanced, passwordless network security. With EAP-TLS, the risk of over-the-air credential theft is null because no credentials are sent over-the-air. Certificates are sent through the encrypted EAP tunnel and cannot be intercepted by a MITM attack. Additionally, certificates are tied to the identity of the user and device and cannot be stolen or removed from the device. With EAP-TLS you can factor in device trust, allowing only trusted managed devices that you know have up-to-date security policies enforced on to the network.

EAP-TLS also provides a far superior end-user experience, primarily by eliminating the burdens associated with using passwords. You can eliminate password change policies that reset all network devices and require users to reconnect their many devices. What’s more, users won’t need to come up with new and complex passwords for every single resource they need to log into.

In contrast, certificates are preset to expire after a chosen interval. This timeframe can be as long or short as the organization desires. Devices equipped with certificates also authenticate and connect to the network faster because there are significantly fewer steps to authenticate a certificate compared to credentials.

Moving to certificate-based 802.1X authentication removes the MSCHAP attack surface entirely, because there is no password hash for an attacker to capture or crack.

Replacing PEAP-MSCHAPv2 With EAP-TLS Is Simple With SecureW2

Continuing to use credentials is a huge risk; all it takes is one stolen credential for a hacker to slip into your network. A 2019 Google survey showed that the majority of people reuse their passwords – this means that capturing one set of credentials can be like snatching a master key that bad actors can use to access additional resources and wreak havoc on an organization-wide scale.

This is why an increasing number of organizations are moving to certificate-based authentication. Some organizations opt to ease the transition to certificate authentication by implementing SecureW2’s simultaneous support for PEAP and EAP-TLS. This top university chose to enroll all incoming students for certificate-based authentication while phasing out credentials in stages with existing users.

The JoinNow Platform, in addition to many other useful features, can properly configure security essentials, such as server certificate validation, on a wide range of bring your own device (BYOD) platforms (Windows, Mac, iOS, Android, Linux, Kindle, and more). Rather than going through a risky and difficult process of manually configuring their personal devices, users can rest assured that they are onboarding in the easiest and most secure manner possible. It also provides a world-class Dynamic PKI, allowing organizations to easily deploy EAP-TLS certificate-based authentication on their campus.

SecureW2 provides affordable options for protection from credential theft. Schedule a demo to see how quickly you can retire MSCHAP and move to certificate-based authentication with JoinNow Cloud RADIUS.

---

Frequently Asked Questions

What does MSCHAP stand for?

MSCHAP stands for Microsoft Challenge-Handshake Authentication Protocol. It isMicrosoft’s version of CHAP, a password-based authentication protocol. The current version, MSCHAPv2, is defined in RFC 2759 and is most commonly used as the inner authentication method inside PEAP for Wi-Fi and as a VPN authentication option.

Is MSCHAPv2 secure?

On its own, no. A captured MSCHAPv2 handshake can be reduced to breaking a single DES key, which dedicated hardware can recover in under a day regardless of password strength. PEAP wraps MSCHAPv2 in a TLS tunnel for over-the-air protection, but that protection fails if the client does not validate the RADIUS server certificate. For long-term security, certificate-based EAP-TLS is the recommended replacement.

What is the difference between MSCHAP and MSCHAPv2?

MSCHAP (MS-CHAPv1, RFC 2433) provides one-way authentication, where the server authenticates the client. MSCHAPv2 (RFC 2759) adds mutual authentication so the client also verifies the server, and it drops the weaker LM hash in favor of the NT hash. Both still rely on the MD4-based NT hash and are vulnerable when a handshake is captured, so neither is safe without a validated TLS tunnel.

How to replace PEAP-MSCHAPv2 authentication?

The recommended alternative is EAP-TLS, a certificate-based 802.1X authentication method. Instead of a password and its hash, each device presents a digital certificate that cannot be intercepted over the air or reused on another device. Because no password hash crosses the network, the MSCHAP cracking attack does not apply. Microsoft has recommended moving to certificate-based authentication such as EAP-TLS for MSCHAPv2-based Wi-Fi and VPN endpoints.