Home page logo

bugtraq logo Bugtraq mailing list archives

Re: MS Chap v2 analysis
From: burtonr () CITRIX COM (Burton Rosenberg)
Date: Wed, 7 Jul 1999 18:15:37 -0400

the parallel structure of generating the challenge response (function
ChallengeResponse() in
www.ietf.org/internet-drafts/draft-ietf-pppext-mschap-v2-03.tex) cuts down
the strength of
the PasswordHash from 16 to 14 bytes.

this should have been addressed in version 2.

given challenge C of 8 bytes (or the "hidden challenge" of version 2),
password hash P of 16 bytes,
the response is:
  < DES_{P1} ( C ) | DES_{P2}(C) | DES_{P3}( C ) >
where, P1 is the first 7 bytes of P, P2 is the second 7 bytes of P, and P3
is the last 2 bytes
of P followed by 5 bytes of zeros.

Break P3 by solving C' = DES_X( C ) for X given known C and C' by brute
force over small number
( 2^16 ) of possibilities for X. This gives the last two bytes of P.



-----Original Message-----
From: Paul Leach [SMTP:paulle () MICROSOFT COM]
Sent: Wednesday, July 07, 1999 4:56 AM
Subject:      MS Chap v2 analysis

In the recently published paper on PPTPv2
(http://www.counterpane.com/pptpv2-paper.html), you state

"5 Analysis of MS-CHAPv2
We do not know why Microsoft chose such a complicated protocol, since this
is not stronger than the following:

The Server sends the Client an 8-byte challenge.
The Client encrypts the 16-byte local password hash with an 8-byte
and sends the Server the 24-byte response, an 8-byte challenge of its own,
and the username.
The Server sends a pass/fail packet with a 24-byte response to the
challenge, which is the user's password-hash-hash encrypted with the
Client's 8-byte challenge."

In fact, the above protocol is considerably weaker than MSCHAPv2.

1. It is subject to a chosen plaintext attack by the server, or by an
attacker. A rogue server can always use a constant challenge (or the
attacker can modify the server's challenge), and precompute a table of
responses for any list of passwords it chooses, making finding the user's
password a mere table lookup. That's because, in this protocol, the
is independent of the username and the client, and depends only on the
password and the server's challenge.

In contrast, MSCHAPv2 creates a challenge by hashing a nonce chosen by the
client with one chosen by the server -- thus neither gets to control what
the challenge is. (Does this clarify your confusion in section 3.1?)

2. Any eavesdopper can recover the local password hash, since it is
encrypted with the server's 8 byte challenge, which was sent in the clear.
This means it can masquerade as the user.

3. Any eavesdropper can recover the user's password-hash-hash, since it is
encrypted with the client's 8 byte challenge, which was sent in the clear.
Once the eavesdropper has the user's password-hash-hash, it can "mutually
authenticate" to that user.

[OK, let's assume that you got steps 2 & 3 reversed -- you meant to say
the challenge was encrypted by the hash (or hash-hash).]

4. It is subject to a chosen plaintext attack by an active attacker on the
mutual authentication step, leading to a precomputed table lookup attack
the password-hash-hash.

The MSCHAPv2 mutual authentication step, by incorporating the client's
response (which is a function of both client's and server's nonce), does
let the client control the server's response, which otherwise would only
depend on the password.


  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]