Fact-checked by Grok 2 weeks ago

MS-CHAP

MS-CHAP ( Challenge-Handshake Authentication Protocol) is a password-based protocol developed by as an extension to the (CHAP) for securing (PPP) connections, particularly in remote access scenarios for Windows networks. Introduced in the late 1990s, MS-CHAP enhances CHAP's challenge-response mechanism by incorporating -specific hashing and encryption methods compatible with and later systems, enabling secure user without transmitting plaintext passwords over the network. It operates through a three-way where the sends a challenge to the client, the client responds with a hashed value derived from the user's password, and the verifies it against stored credentials. MS-CHAP exists in two primary versions: MS-CHAP version 1 (MS-CHAPv1), defined in RFC 2433 and published in 1998, which supports both and NT-compatible responses but lacks ; and MS-CHAP version 2 (MS-CHAPv2), specified in RFC 2759 and released in 2000, which introduces bidirectional to verify both the client and , uses including , , , and , and includes features for password changes during . Key to its design is the use of non-reversible hashes to protect credentials, with MS-CHAPv1 employing a 24-octet response based on the hash of the version of the user's and the 8-octet challenge, while MS-CHAPv2 refines this by incorporating the username and for additional integrity. The protocol is negotiated via LCP option 3 in , using algorithm identifiers 0x80 for v1 and 0x81 for v2, and it supports error handling through specific failure codes (e.g., 691 for invalid credentials or 648 for password expired). Widely deployed in legacy VPNs, dial-up services, and environments, MS-CHAP has been integral to networking but is considered vulnerable to dictionary attacks and offline cracking due to its reliance on weaker hashes like , prompting recommendations for stronger alternatives like EAP-TLS in modern setups. As of 2025, has deprecated or restricted MS-CHAPv2 in newer Windows versions due to these vulnerabilities, recommending certificate-based alternatives like EAP-TLS. Despite these limitations, its integration with protocols like MPPE for encryption has made it a foundational element in Windows-based remote access security.

Introduction

Overview

MS-CHAP, or Challenge-Handshake Authentication Protocol, is a developed by as an extension to the standard (CHAP). It enables secure user authentication in (PPP) connections, particularly for remote access scenarios, by incorporating Microsoft-specific enhancements such as support for between client and server and mechanisms for password changes during the authentication process. The core purpose of MS-CHAP is to provide a challenge-response mechanism that authenticates users in dial-up and (VPN) environments without transmitting passwords, thereby improving security over simpler methods like the (PAP). This protocol integrates seamlessly with Windows networking features, allowing remote workstations to authenticate against domain controllers while maintaining compatibility with LAN-based user experiences. MS-CHAP builds directly on the framework established in RFC 1994 for CHAP, which uses a three-way involving a challenge, response, and verification, but it introduces proprietary algorithms, attribute formats, and negotiation identifiers (such as CHAP Algorithm 0x80) tailored to Microsoft's ecosystem. It was first introduced with in 1995 to offer enhanced security for remote access compared to , with subsequent compatibility extended to later versions like and Windows 95. There are two primary versions: MS-CHAPv1 and the improved MS-CHAPv2.

History

MS-CHAP was developed in 1994 by as an extension to the (CHAP) to enable for remote Windows workstations and servers over (PPP) connections in Dial-Up Networking and (PPTP), addressing limitations in standard CHAP for Microsoft networking environments. It was first implemented in , released on May 30, 1995. The initial version, MS-CHAPv1, was introduced with on May 30, 1995, and later supported in and Windows 95. It was subsequently standardized by the (IETF) in 2433, published in October 1998. MS-CHAPv2 was rolled out in 4 in October 1998 and backported to and , enhancing security features over the original version. This update was formalized in RFC 2759, published in January 2000. Deprecation efforts began with the removal of MS-CHAPv1 support in , released in January 2007, due to security concerns. For MS-CHAPv2, restrictions were introduced in version 22H2, released in September 2022, where it is blocked by default when Windows Defender Credential Guard is enabled on compatible devices. Following disclosures of vulnerabilities in the and , including the Blast-RADIUS (CVE-2024-3596) in July 2024, has faced increased scrutiny over MS-CHAP's use in legacy systems and has recommended migrating to certificate-based methods, such as EAP-TLS, particularly for and VPN connections, with guidance intensifying around 2022-2025 to align with modern security standards.

Protocol Mechanics

Authentication Flow

MS-CHAP operates as an within the () framework, specifically during the authentication phase following the establishment of the Link Control Protocol (LCP) configuration. It uses distinct identifiers in PPP packets: 0x80 for MS-CHAP and 0x81 for version 2. The process begins with the () generating and sending a Challenge packet to the client (peer). This packet includes a random challenge value—8 bytes for or 16 bytes for version 2—along with the peer's identifier (Name field), which typically contains the username. The client then computes a response based on the provided challenge, its username, and , producing a hashed credential value. The Response packet sent by the client incorporates this response— a 49-byte Value field for (comprising 24-byte LAN Manager response, 24-byte NT response, and 1-byte flags) or 49 bytes for version 2 (16-byte peer challenge, 8-byte reserved, 24-byte NT response, and 1-byte flags)—plus the Name field. Upon receiving the Response, the server verifies the hashed credentials against stored user data, using like the NT password hash derived from MD4. If valid, the server sends a Success packet; for version 1, this has an empty Value field, while for version 2, it includes a 42-byte authenticator response value to enable . In version 2, following initial success, the client challenges the server by verifying this authenticator response using the peer challenge and other shared elements, confirming the server's knowledge of the user's . If authentication fails, the server issues a packet containing an (e.g., E=691 for invalid credentials or 648 for access denied) and a retry flag (R=1 to allow reattempt, R=0 to terminate). Error handling in MS-CHAP incorporates retry mechanisms through the Failure packet's MS-CHAP-Error attribute, which may include a new challenge for resubmission or prompts for password changes (e.g., E=648 triggering a Change-Password packet with code 7 in version 2). The client can resubmit a Response using the updated challenge if retries are permitted, facilitating robust authentication without immediate session termination. This sequence ensures a challenge-response exchange integrated seamlessly into PPP's control protocol exchanges.

Cryptographic Components

MS-CHAP employs as the primary for initial password hashing in both versions, producing a 16-byte NT password hash from the user's password via the NtPasswordHash function. In MS-CHAPv1, the optional and now-deprecated () hash is also supported, derived from OEM-encoded passwords up to 14 characters using two encryptions on fixed constants, yielding another 16-byte hash for with older systems. The protocol utilizes the (DES) algorithm in Electronic Codebook (ECB) mode for response generation. The 16-byte NT password hash serves as the basis for a 21-byte key material by appending five null bytes, which is then divided into three 7-byte segments; each segment is adjusted for to form a 56-bit DES key (expanded to 64 bits). These keys encrypt the 8-byte in sequence, producing three 8-byte blocks that concatenate to form the 24-byte NT response. A similar process applies to the LM hash in MS-CHAPv1, where the 16-byte LM hash is zero-padded to 21 bytes, divided into three 7-byte segments adjusted for , and used to perform three DES encryptions on the 8-byte , producing the 24-byte LM response. In MS-CHAPv2, enhances key derivation for greater integrity, particularly in generating the master session key for encryption protocols like MPPE. The NT password hash is first hashed again with to produce an NtPasswordHashHash, which is then input to along with the NT-Response: the master session key is the first 16 bytes of (NtPasswordHashHash || NT-Response || "This is the MPPE Master Key"), where "This is the MPPE Master Key" is a fixed 27-byte constant. The peer challenge, authenticator challenge, and username are first combined to form an 8-byte effective challenge as the first 8 bytes of (Peer-Challenge || Authenticator-Challenge || Username). This effective challenge is then encrypted using (as described for the NT response) to produce the 24-byte NT-Response. The MPPE master key then uses this NT-Response along with NtPasswordHashHash and the magic constant in the computation as noted above. This supports 40-bit or 128-bit session keys, depending on . MS-CHAPv1 relies solely on /-derived keys without . Challenges provide the necessary in the , with the generating an 8-byte in MS-CHAPv1 or a 16-byte in MS-CHAPv2, both drawn from a adhering to established randomness standards to prevent predictability. The peer similarly generates a 16-byte challenge in MS-CHAPv2 for . MS-CHAP is identified by specific algorithm identifiers in PPP's LCP option: 0x80 for version 1, relying on and ; and 0x81 for version 2, which incorporates for additional hashing and integrity checks. These components integrate into the flow by processing challenges against password hashes to produce verifiable responses.

Versions

MS-CHAPv1

MS-CHAPv1, defined in RFC 2433 published in October 1998, extends the (CHAP) for use in (PPP) connections, providing unilateral authentication where the authenticator verifies the peer but not vice versa. This version introduces Microsoft-specific enhancements to support Windows networking environments, including compatibility with legacy password hashing mechanisms and mechanisms for password changes during the authentication process. Unlike standard CHAP, which relies on hashing, MS-CHAPv1 employs DES-based challenge responses derived from the user's (LM) or NT password hashes, enabling integration with and earlier systems without requiring plaintext passwords. The response in MS-CHAPv1 consists of a 49-byte : a 24-byte LM-response for with legacy systems using the weaker LM (limited to 14 uppercase characters), a 24-byte NT-response based on the stronger NT , and a 1-byte flags field indicating which response to prioritize (with the LM-response deprecated but zero-filled for compatibility). This dual-response format improves upon standard CHAP by accommodating diverse Windows clients, including older ones reliant on LM hashes, while also supporting reason codes in the protocol's packet to provide detailed error information, such as authentication rejection due to invalid credentials (code E=691). Additionally, MS-CHAPv1 allows the to initiate a change if the current credentials fail, enhancing usability in dial-up scenarios without exposing passwords in clear text. MS-CHAPv1 is commonly integrated with Microsoft Point-to-Point Encryption (MPPE) for securing PPP sessions, particularly in (PPTP) virtual private networks, where session keys are derived from the credentials using functions like LmPasswordHash and NtPasswordHash to support 40-bit, 56-bit, or 128-bit . However, its reliance on outdated , such as and LM hashes, along with the absence of , limits its security in modern contexts. Due to these weaknesses, MS-CHAPv1 has been deprecated, with removing support for it in and later versions starting in 2007.

MS-CHAPv2

MS-CHAPv2, the second version of Microsoft's Challenge-Handshake Authentication Protocol extensions for PPP, was defined in RFC 2759, published in January 2000 as an informational specification. This version introduces key enhancements over its predecessor, including mutual authentication between the client (peer) and server (authenticator), as well as support for password changes directly over the authenticated link. These features address limitations in earlier authentication protocols by ensuring both parties verify each other's identity and allowing secure password updates without requiring a separate connection. The protocol operates within the PPP framework, enabled by negotiating CHAP algorithm identifier 0x81 during LCP authentication protocol exchange. Upon receiving the client's identity, the server sends a Challenge packet containing a 16-octet random challenge value. The client responds with a Response packet that includes its own 16-octet peer challenge, enabling the server to later prove its identity to the client. If authentication succeeds, the server sends a Success packet with an 8-octet authenticator response derived from the peer challenge, confirming mutual trust; failure results in a Failure packet with an error code. The Response packet's Value field is 49 octets long, structured as follows: 16 octets for the peer , 8 octets reserved (set to zero), 24 octets for the NT-Response (a hash-based proof of knowledge of the user's NT password hash), and 1 octet for flags (initially set to zero). A distinctive mechanism is the server-to-client in the initial packet, which the client incorporates into its NT-Response using NTLM-style hashing. Additionally, MS-CHAPv2 supports the MS-CHAP-CPW attribute via a dedicated Change-Password packet (code 7, 586 octets total), allowing the client to request and perform password changes post-authentication, such as when a password expires. Compared to MS-CHAPv1, MS-CHAPv2 rejects legacy LM hashes entirely, relying solely on the -Response derived from the NT password hash and encryption, eliminating support for the weaker LM hash. These improvements eliminate weaker hash dependencies and enable integration with modern authentication frameworks. It supports encapsulation within the (EAP) for broader use in network access scenarios. MS-CHAPv2 has become the default method in modern Windows operating systems, starting from , and remains widely adopted for PPP-based connections. It is required in various implementations for secure remote access, particularly when encapsulated as EAP-MSCHAPv2, which appears as "Secure password (EAP-MSCHAP v2)" in Windows network policies. As of April 2025, Microsoft recommends moving away from MS-CHAPv2-based connections (e.g., PEAP-MSCHAPv2, EAP-MSCHAPv2) to certificate-based for improved .

Security Aspects

Features

MS-CHAP incorporates several enhancements over traditional CHAP to improve security and in PPP environments. In MS-CHAPv2, is achieved through a peer challenge included in the client's Response packet and an authenticator response in the server's Success packet, allowing both parties to verify each other's identity and mitigating risks during the initial . A key usability feature is the integrated password management protocol, which enables secure password changes over encrypted channels. This is facilitated by the Change-Password packet (Code 7), triggered after a password expiration error in the Failure packet, using encrypted fields like Encrypted-Password and Encrypted-Hash derived from NT password hashes to minimize exposure during updates. MS-CHAP seamlessly integrates with protocols by deriving session keys directly from responses. For Microsoft Point-to-Point (MPPE), keys of 40-bit, 56-bit, or 128-bit lengths are generated from MS-CHAPv2 credentials using functions like Get_Start_Key and hashing on the NT-Response and peer challenge, enabling immediate of PPP traffic without additional . The supports broad compatibility through features like -based , where usernames can include qualifiers (e.g., "domain\user" or "user@domain") in the Name field for enterprise environments. Additionally, it includes retry logic in the packet, with a retry flag (R=1) providing a new challenge for failed attempts while (R=0) disables further retries to prevent abuse. An EAP variant, EAP-MS-CHAPv2, encapsulates the MS-CHAPv2 exchange within the framework for tunneled authentication in 802.1X networks. This allows legacy MS-CHAPv2 compatibility in modern wireless and wired access scenarios, such as PEAP or TTLS tunnels.

Vulnerabilities

MS-CHAP, both in version 1 and 2, relies on that are now considered weak, particularly the use of single encryption in key derivation processes. In MS-CHAPv1, the LM-response is computed using to encrypt a challenge with portions of the LM hash, which splits passwords into weak 14-character halves and employs a reduced key space, making it susceptible to brute-force attacks and lookups. By 2012, tools like ASLEAP had demonstrated practical cracking of these responses using precomputed tables or dictionary attacks, exploiting the vulnerability to recover passwords in minutes for weak entries. MS-CHAPv2 improves on this by using NTLM hashes but remains vulnerable to offline dictionary attacks when authentication handshakes are captured, as the challenge-response allows extraction of the NT hash for cracking. Attackers can use tools like to perform dictionary or brute-force attacks on the unsalted NTLM hash derived from the captured MS-CHAPv2 exchange, often succeeding against common passwords in hours on modern hardware. This susceptibility arises because the protocol transmits responses that enable direct offline computation of the underlying password hash without requiring online interaction. The protocol lacks , as session keys for (such as in MPPE) are derived directly from static hashes like the NT hash, allowing an attacker who compromises the to retroactively decrypt any previously captured traffic. Passive eavesdroppers can thus derive session keys from the static secret if they obtain the NT hash through other means, compromising the of past sessions without needing . This design contrasts with modern protocols that use ephemeral keys to ensure compromised long-term secrets do not affect prior communications. Implementation flaws exacerbate these issues; for instance, PEAP-MS-CHAPv2 is intended to protect credentials via a , but if the tunnel is not properly validated or is subject to man-in-the-middle attacks through server spoofing, attackers can steal credentials by decrypting the inner MS-CHAPv2 exchange. In MS-CHAPv1, the LM-response can be trivially reversed due to the predictable key schedule and weak padding, allowing direct recovery of password components without full brute-force effort. acknowledged a specific in PEAP-MS-CHAPv2 configurations in , highlighting risks from improper validation leading to credential theft. Recent developments underscore MS-CHAP's declining trust, with Credential Guard in Enterprise and Education editions (version 22H2 and later, released in 2022) disabling it by default to prevent exposure of credentials during , as the feature isolates secrets in a virtualized to block hash extraction. Legacy use of MS-CHAP in VPNs has contributed to vulnerabilities in 2024, such as the Blast- attack (CVE-2024-3596), which exploits implementations to downgrade or impersonate MS-CHAP authentications, enabling credential theft in unprotected deployments. These issues have prompted recommendations to phase out MS-CHAP in favor of certificate-based alternatives to mitigate ongoing risks in enterprise networks.

Applications and Deprecation

Primary Uses

MS-CHAP was primarily developed as an extension of the (CHAP) for use within (PPP) connections, particularly in Windows environments for remote access scenarios. Its original intent focused on authenticating users over dial-up, ISDN, and links in legacy networking setups. In these PPP-based dial-up contexts, MS-CHAP integrated seamlessly with Windows operating systems to secure initial connections before establishing encrypted sessions. A core deployment of MS-CHAP has been in virtual private network (VPN) authentication, especially as part of the Point-to-Point Tunneling Protocol (PPTP) defined in RFC 2637, where it serves as the foundational authentication method for remote access. Within PPTP, MS-CHAP generates keys for Microsoft Point-to-Point Encryption (MPPE), enabling session encryption over tunneled PPP links and supporting secure remote worker connectivity to corporate networks. This integration made MS-CHAP essential for early VPN implementations in enterprise settings reliant on Microsoft infrastructure. In wireless networks, MS-CHAP is commonly employed within WPA2-Enterprise configurations through the protocol outlined in RFC 2865 and port-based access control, often encapsulated in Protected Extensible Authentication Protocol (PEAP) for enhanced security. Here, it authenticates users against centralized servers during the association process, facilitating secure access to enterprise networks. MS-CHAP also integrates with server environments for domain authentication, particularly supporting in Windows domains and legacy RADIUS servers such as Microsoft's Internet Authentication Service (IAS) or Cisco's implementations. These integrations allow MS-CHAP to validate credentials against directory services during network access requests, commonly seen in hybrid setups combining Windows servers with Cisco networking equipment. As of 2025, MS-CHAP persists in some enterprise deployments for and VPN , particularly in environments maintaining compatibility with older Windows clients and infrastructure, though its use is increasingly limited due to evolving security standards. For instance, 2025 continues to support MS-CHAPv2 in RADIUS-based scenarios for in VPN and wireless access points.

Modern Status and Alternatives

As of 2025, MS-CHAP remains fully supported in Windows 10 and 11 for compatibility with legacy VPN and Wi-Fi authentication protocols, but its use is significantly restricted by security features such as Credential Guard, which is enabled by default on eligible devices in Windows 11 version 22H2 and later. Credential Guard isolates NTLM credentials to prevent exposure, blocking single sign-on (SSO) for MS-CHAPv2-based connections like PEAP-MSCHAPv2, thereby requiring users to enter credentials manually for each session. In Linux environments, MS-CHAP is supported through extensions like the rlm_mschap module in FreeRADIUS server version 3.x and higher, enabling integration with RADIUS-based systems for dial-up and wireless authentication. These implementations allow ongoing use in open-source setups but depend on administrator configuration to mitigate known vulnerabilities. Deprecation of MS-CHAP is driven by evolving standards emphasizing stronger beyond password-based methods. The NIST Special Publication 800-63B recommends limiting reliance on memorized secrets (passwords) for authentication assurance levels AAL2 and AAL3, instead favoring (MFA) and cryptographic authenticators to reduce risks from credential compromise. Similarly, the EU's NIS2 Directive (Directive (EU) 2022/2555), which entered into force in January 2023 and requires transposition by member states by October 2024, mandates cybersecurity risk-management measures for critical sectors, including robust access controls; ENISA's technical implementation guidance under NIS2 promotes phishing-resistant MFA as a for entities handling . Recommended alternatives to MS-CHAP prioritize certificate-based and phishing-resistant mechanisms for improved security in enterprise networks. EAP-TLS provides using digital s, eliminating password transmission and enabling device verification without shared secrets. For transitional setups, EAP-TTLS or PEAP can tunnel an inner EAP-TLS method, combining server validation with client authentication to phase out legacy password reliance. In modern VPN deployments, protocols like offer a lightweight alternative using pre-shared keys (PSK) or , bypassing challenge-response mechanisms entirely while supporting zero-trust principles. Migration to these alternatives faces challenges from entrenched systems in enterprises, where older and requirements prolong MS-CHAP usage despite risks. Tools such as SecureW2's PKI facilitate the transition from PEAP-MSCHAPv2 to EAP-TLS by automating and , allowing dual-protocol support during rollout to minimize disruptions. However, integrating these solutions often requires updating servers, client devices, and policies, which can strain resources in large-scale environments. Looking ahead, industry trends point toward of MS-CHAP as zero-trust architectures gain dominance, emphasizing continuous verification and phishing-resistant methods over perimeter-based, password-derived .

References

  1. [1]
    RFC 2433: Microsoft PPP CHAP Extensions
    This document describes Microsoft's PPP CHAP dialect (MS-CHAP), which extends the user authentication functionality provided on Windows networks to remote ...
  2. [2]
    RFC 2759: Microsoft PPP CHAP Extensions, Version 2
    ### Summary of MS-CHAP v2 (RFC 2759)
  3. [3]
    [MS-CHAP]: Overview - Microsoft Learn
    Jun 24, 2021 · The Extensible Authentication Protocol Method for Microsoft CHAP messages are carried from the EAP peer to the network access server (NAS) over ...
  4. [4]
    Considerations and known issues when using Credential Guard
    Apr 22, 2025 · Credential Guard may restrict credentials, affect NTLMv1, MSCHAPv2, and some delegation, and block certain authentication capabilities. It also ...Upgrade considerations · Wi-fi and VPN considerations
  5. [5]
    RFC 2433 Microsoft PPP CHAP Extensions - IETF
    MS-CHAP is closely derived from the PPP Challenge Handshake Authentication Protocol described in RFC 1994 [2], which the reader should have at hand.
  6. [6]
    RFC 2759 - IETF
    * MS-CHAP-V2 is enabled by negotiating CHAP Algorithm 0x81 in LCP option 3, Authentication Protocol. * MS-CHAP-V2 provides mutual authentication between peers ...
  7. [7]
    RFC 2433 - Microsoft PPP CHAP Extensions - IETF Datatracker
    1. Abstract The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links. · 2. · 3. · 4.
  8. [8]
    RFC 2759 - Microsoft PPP CHAP Extensions, Version 2
    This document describes version two of Microsoft's PPP CHAP dialect (MS-CHAP-V2). MS-CHAP-V2 is similar to, but incompatible with, MS- CHAP version one.
  9. [9]
    Deriving Keys for use with Microsoft Point-to-Point Encryption (MPPE)
    This document describes the method used to derive initial MPPE session keys from a variety of credential types.Missing: flow | Show results with:flow
  10. [10]
    https://datatracker.ietf.org/doc/html/rfc3079
  11. [11]
    https://datatracker.ietf.org/doc/html/rfc1994
  12. [12]
    MSCHAP Version 2 [Support] - Cisco
    MSCHAP Version 2. First Published: January 23, 2003 Last Updated: October 14, 2009. The MSCHAP Version 2 feature (introduced in Cisco IOS Release 12.2(2)XB5) ...
  13. [13]
    Extensible Authentication Protocol (EAP) for network access
    Jul 9, 2025 · The Extensible Authentication Protocol (EAP) is an authentication framework that allows for the use of different authentication methods for secure network ...
  14. [14]
    draft-kamath-pppext-eap-mschapv2-02 - IETF Datatracker
    This document defines the Microsoft EAP CHAP Extensions Protocol, Version 2, which encapsulates the MS-CHAPv2 protocol defined in RFC 2759, within EAP as ...Missing: flow | Show results with:flow
  15. [15]
    joswr1ght/asleap: Asleap - Cisco LEAP and Generic MS ... - GitHub
    This makes asleap more of a generic MS-CHAPv2 dictionary attack tool, which is fine by me. UPDATE - 2007-5-10. I spent some time updating asleap and came to ...Missing: brute- Rainbow Tables 2012
  16. [16]
    Attacking MS-CHAP v2 - ITSEC Games
    Sep 11, 2012 · Asleap is a tool designed to recover weak LEAP (Cisco's Lightweight Extensible Authentication Protocol) and MS-CHAP passwords. It uses a ...
  17. [17]
    [PDF] Cryptanalysis of Microsoft's PPTP Authentication Extensions (MS ...
    The most significant changes from MS-CHAPv1 to MS-CHAPv2 are: – The weaker LAN Manager hash is no longer sent along with the stron- ger Windows NT hash. This is ...
  18. [18]
    sensepost/assless-chaps: Crack MSCHAPv2 challenge ... - GitHub
    Aug 5, 2021 · Assless CHAPs is an efficient way to recover the NT hash used in a MSCHAPv2/NTLMv1 exchange if you have the challenge and response (eg from a WiFi EAP WPE ...
  19. [19]
    Cryptanalysis of Microsoft's PPTP Authentication Extensions (MS ...
    This paper examines MS-CHAPv2 and discusses how well it addresses the security weaknesses outlined in [SM98].Missing: forward secrecy
  20. [20]
    PEAP-MSCHAPv2 Vulnerability Allows For Credential Theft
    PEAP-MSCHAPv2 is vulnerable due to misconfigurations and weak encryption, allowing attackers to decrypt user credentials via spoofed networks.
  21. [21]
    Microsoft Security Advisory 2876146
    Aug 4, 2013 · Microsoft is aware of a public report that describes a known weakness in the Wi-Fi authentication protocol known as PEAP-MS-CHAPv2.Missing: DES | Show results with:DES
  22. [22]
    PPP Security - Wayne Pollock's
    Aug 22, 2017 · Unlike regular CHAP , MS-CHAPv2 requires both parties to authenticate to the other. Only one side has to send the MS-CHAPv2 request; if ACK'd ...<|control11|><|separator|>
  23. [23]
    https://wpollock.com/AUnixSec/PPPsecurity.htm
  24. [24]
    Blast-RADIUS Attack: RADIUS/UDP and MD5 Authentication - Rublon
    Jul 16, 2024 · The researchers at Cloudflare have recently discovered a Blast-RADIUS vulnerability. The vulnerability is tracked as CVE-2024-3596.<|control11|><|separator|>
  25. [25]
    MS-CHAP-Challenge - FreeRADIUS
    1. Introduction. Microsoft created Microsoft Challenge-Handshake Authentication Protocol (MS-CHAP) [4] to authenticate remote Windows workstations, providing ...<|control11|><|separator|>
  26. [26]
    Configure and Understand the PPP CHAP Authentication - Cisco
    This document describes how the Challenge Handshake Authentication Protocol (CHAP) verifies the identity of a peer by means of a three-way handshake.
  27. [27]
    RFC 2637 - Point-to-Point Tunneling Protocol (PPTP)
    This document specifies a protocol which allows the Point to Point Protocol (PPP) to be tunneled through an IP network.
  28. [28]
    PPTP Frequently Asked Questions - Cisco
    A. MPPE requires Microsoft Challenge Handshake Authentication Protocol (MS-CHAP). It only works with RADIUS or local authentication, and the RADIUS server must ...
  29. [29]
    Implementing PEAP-MS-CHAP v2 authentication for Microsoft PPTP ...
    MS-CHAP v2 is a password-based authentication protocol which is widely used as an authentication method in PPTP-based (Point to Point Tunneling Protocol) VPNs.
  30. [30]
    RFC 2865 - Remote Authentication Dial In User Service (RADIUS)
    This document describes a protocol for carrying authentication, authorization, and configuration information between a Network Access Server
  31. [31]
    Deploy Password-Based 802.1X Authenticated Wireless Access
    Apr 28, 2023 · This guide explains how to build upon a core network by providing instructions about how to deploy Institute of Electrical and Electronics ...Missing: deprecated | Show results with:deprecated
  32. [32]
    How to authenticate against Active Directory from Cisco IOS
    Sep 4, 2008 · The first step is to get IAS installed and registered in Active Directory. Microsoft recommends that IAS be loaded on domain controllers (and ...
  33. [33]
    Cisco Identity Services Engine Administrator Guide, Release 3.3
    In Cisco ISE, you can authenticate administrators via an external identity store such as Active Directory, LDAP, or RSA SecureID. There are two models you can ...
  34. [34]
    Zyxel Firewall Authentication Compatibility with Windows Server 2025
    Aug 5, 2025 · Note: As of April 2025, Windows Server 2025 continues to support MS-CHAPv2 for authentication. However, it's important to note that Windows ...