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.)