From: Bill Stewart <stewarts@ix.netcom.com>
Date: Sun, 26 Jan 1997 14:54:11 -0800 (PST)
To: Amanda Walker <amanda@intercon.com>
Subject: Re: Hi again, and an invitation to kibitz
In-Reply-To: <199701180202.VAA11013@beast.brainlink.com>
Message-ID: <3.0.1.32.19970126145141.005b4068@popd.ix.netcom.com>
MIME-Version: 1.0
Content-Type: text/plain


In addition to David Wagner's comments, I'd like to point out
several more weaknesses.
- Would Kerberos work just as well?  No sense reinventing the 3-headed dog.
- You're not authenticating the server to the client.
- If the challenge is different every time, the server needs to 
  keep the user's password in plaintext (unlike Unix encrypted passwords.)
  This means that attacks on the server's file system can steal it,
  and since the password is used for session encryption, it can be
  used to forge sessions as well.
- Alternatively, if the challenge is always the same (per user),
  then even one eavesdrop kills you, as with Unix passwords.
- Since you're using the same 7-byte password hash for the
  first third of the authentication as for the session key,
  the dictionary attack on E(challenge, First-seven-bytes)
  gives you the session key, so you can eavesdrop just fine.
  If the password is too short, you can then dictionary-attack MD4
  to find it also.

- There's a Diffie-Hellman variant that can do logins.  
  Unfortunately, it's patented (by some guy from Siemens in Paderborn DE, 
  who patented it in Germany about 2 years before I rediscovered it, 
  and patented it in the US about 6 months before :-)  
  It covers any login methods using commutative hashes H1(H2(x)) == H2(H1(x)).
  The Siemens version extends it to authenticate both ends to each other;
  I extended it to get a session key for encryption and/or authentication.
  This really shouldn't have been patentable - my rediscovery shows that
  it must be pretty obvious to anyone skilled in the trade :-), and rather
  than reinventing the wheel, I was reinventing the hubcap or tire swing....

> In article <199701140755.CAA04514@mail.intercon.com>,
>Amanda Walker <amanda@intercon.com> wrote:
>> (a) Server sends 8-byte challenge to client
>> (b) Client sends Microsoft NT authentication response to the server
>>     (take the password in Unicode form, do an MD4 hash, pad with 0s to 21
>>     bytes, split into 3 7-byte groups, use these as DES keys to encrypt
>>     the challenge three times, send the 24-byte result as the response).
>> (c) If authentication fails, close the connection.
>> (d) If authentication succeeds, all subsequent traffic is enccrypted with
>>     DES in CFB mode.  Until April :), the DES key used is taken from the
>>     first 7 bytes of the MD4 hash of the password (after April, we expect
>>     to switch to Diffie-Hellman key exchange first, followed by a revised
>>     authentication handshake).
>
At 11:20 AM 1/17/97 -0800, David Wagner wrote:
>Some weaknesses:
>- It doesn't resist dictionary attacks (no salt) when the attacker can make
>    one active probe (forge a fixed challenge and get the client's response).

In particular, an 8 byte challenge is nowhere near enough, though the 
average million-dollar DES-cracker won't be as easy to adapt for 2**64 
cycles of hash+DES*3 - and don't handle each third separately!
At least do something like 3DES-EDE and return an 8-byte response,
or hash the three output bytes together and send the hash.
Using >=16 bytes of challenge would be better, or >=24 if you 
want printable challenges.

>- It doesn't stop replay attacks (replay a fixed challenge, now the same DES
>    key is used, so replay DES-encrypted session data).

You may not be able to replay a given challenge usefully, assuming it's
different each time, but MITM attacks work ok after you've cracked the
password by dictionary attack in the previous round.

>- DES-encryption doesn't provide message authentication against active
>    attacks; use a MAC too.
>- You should use independent DES keys for each direction of the connection.
>- Also the DES encryption key doesn't change for each connection.  It should.



#			Thanks;  Bill
# Bill Stewart, +1-415-442-2215 stewarts@ix.netcom.com
# You can get PGP outside the US at ftp.ox.ac.uk/pub/crypto/pgp
#     (If this is a mailing list, please Cc: me on replies.  Thanks.)