Microsoft Challenge Handshake Authentication Protocol

From Hill2dot0
(Redirected from MS-CHAP)
Jump to: navigation, search

Microsoft CHAP (MS-CHAP) is the often-used Microsoft proprietary version of the Challenge Handshake Authentication Protocol (CHAP). Like CHAP, MS-CHAP relies on a hash of the user’s password and a random challenge string to authenticate the remote user to an authentication server.

MS-CHAP v1 (version 1) has often been criticized for its lack of real security, despite its using CHAP. This criticism refers to MS-CHAP’s effort to be backwards compatible with older Windows workstations. Using LANManager in these situations, the encoding of the password and the challenge was cryptographically weak.

Microsoft attempted to improve this vulnerability in MS-CHAP v2 (version 2). By removing the backwards compatibility option from MS-CHAP v2, it can now support more modern and robust protection for remote authentication. Furthermore, MS-CHAP v2 is able to support server authentication as well, providing some protection that the end user is authenticating to a trusted machine at the same time, that the remote server authenticates the end user.

This mutual authentication process works as follows:

  1. The remote access server (RAS) sends a session ID and a challenge string to the remote client.
  2. The remote client responds with a string that includes the user name, a challenge string to the server, and a hash of the received challenge, the session ID, and the user password.
  3. The remote server checks the hash and compares it to its own hash of the user’s password, sent challenge, and session ID. If the comparison is successful, the user is granted access to the server. The reply packet from the server to the client indicating success or failure of login also contains the server’s response to the clients challenge.
  4. The remote client verifies the authentication response and either uses the connection or terminates it.

By using mutual authentication, MS-CHAP v2 prevents some of the attacks to which v1 was susceptible. Despite this, there is no external authentication of either the remote client or the server. Thus, remote clients can not be assured of the identity of the server they log into—only that they have been granted access to it in a secure manner.