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.
No?
-burt
> -----Original Message-----
> From: Paul Leach [SMTP:paulleat_private]
> Sent: Wednesday, July 07, 1999 4:56 AM
> To: BUGTRAQat_private
> 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
> challenge
> 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
> Client's
> 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
> active
> attacker. A rogue server can always use a constant challenge (or the
> active
> 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
> response
> 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
> that
> 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
> on
> 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
> not
> let the client control the server's response, which otherwise would only
> depend on the password.
>
> Paul
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:51:49 PDT