p>
Dear DDJ,
I have a few comments about Daniel Fremberg's interesting article "The Mithra Authentication Protocol" (DDJ, May 2003). In a shared-key protocol like Mithra, there is no need to send out the password at all, hashed or otherwise.
Furthermore, Daniel's protocol generates a hash based on a server-provided nonce, server's IP, client's IP, and the secret password. However, a man-in-the-middle (MITM) will have access to two of these parameters, thereby reducing the usefulness of these additional parameters. In his desire to eliminate an MITM, Daniel inserts the client's IP address into some kind of hash. In many cases, the client will be behind a NAT router and will not know the public IP address that the server will see. The Mithra protocol as implemented will fail in this fairly common case. In general, the IP addresses are not a very reliable way to verify with whom you are communicating, and should be avoided. Daniel acknowledges this later in the article.
I once had to design a simple protocol for a product long since forgotten, and used the following approach that achieves similar goals in a simpler manner:
1. Decide on a username and a master key to be provided to the client via e-mail, fax, and so on. The server keeps the username and password in a database.
2. When the client wants to communicate with the server, it sends in only the username to initiate contact. The server never initiates contact first.
3. The server looks up the username and retrieves the corresponding password. It prepares a response packet and encrypts it with the master password. The encrypted packet is then sent to the client.
4. Upon receiving the encrypted response, the client uses the master key it has stored locally to decrypt the response.
You can build on this by having the server create a session key and insert it in the first message, which is already encrypted with the master key. From then on, the session key is known to both parties and further communication can be encrypted with the new session key. This reduces the amount of text encrypted with the same password. An MITM attack would not work since the packet in which the session key is sent is encrypted with the master key, and the master key is never sent out. Also note that the server can change the master key periodically, and relay it to the client in a packet encrypted with the session key. That way, an MITM can collect only a limited number of first-contact packets encrypted with the same master key. In addition, the user needs to enter the master key only once when his account is activated. From that point on, the user need not enter a password at all since the program manages it locally and changes it at certain intervals as requested by the server. This eliminates the need to force people to change (and remember) their passwords frequently on their own.
Please note that I am not suggesting my protocol would be secure in today's world, but rather, I'm trying to illustrate a simpler way to implement a protocol using a shared secret key. In this scheme, the biggest weakness would be the first packet the server sends out. Its contents should contain enough random filler data to make it more difficult to launch a brute-force attack. In my implementation, valid data and random filler data are intermixed by shuffling them 16-bytes at a time. The table recording the correct position of each block is computed based on an algorithm seeded with the master key. The table is recreated by the client since it already knows the master key and the algorithm used. The client then rearranges the 16-byte blocks according to the table and retrieves the plaintext data. The format of the packet, field sizes, and the life are known to both parties. This extra step makes life more difficult for MITM, thereby strengthening the protocol.
Tark Yetiser
Dear DDJ,
I read the article "The Mithra Authentication Protocol" (DDJ, May 2003) by Daniel Fremberg with interest. While reading, I took up the challenge Daniel formulated at the end—is there a way to attack from the middle? Daniel states the nonce is used only once; in fact, it is used twice. Mallory can intercept the nonce when it is sent to Bob and when Bob returns the message to Alice, Mallory knows the nonce is used in that message. Furthermore, Mallory knows the IP address of Alice and Bob. One thing Mallory does not know is the password. So Mallory knows: Hash(pwd+IPClient+ IPServer+nonce) and knows IPClient+ IPServer+nonce. Well, with a password of six digits, this is about 36 bits of unknown message! A fast search on the Internet tells me there are accelerators to calculate a HASH-1 over a kilobyte in less than 10 msec. Or 100.0000 per sec or 36 bits in eight days. The six bits per character can probably be narrowed when the characters are not machine generated or can be distributed over more machines.
Jan Harm de Boer
Daniel responds: Jan, thanks for your note. Your observations are dead-on right. Obviously, the password is the single most critical component of the authenticator, since all the other values are assumed to be known by the attacker. This is the reason why great care must be taken in generating passwords that are "hard-to-guess." Although I would argue that your estimation of 36 bits of entropy in a six-digit password is a bit optimistic. Six digits = 100,000 different possible values, which gives us an average of 50,000 "passwords" before we find the one that matches. Calculating the base-2 logarithm (to determine the number of bits needed to represent 50,000 values) gives us: log2(50,000)=15.6 bits, which is considerably less than 36 bits. I'd choose a longer password that included characters as well. But he is nevertheless correct in his investigation, brute-forcing the authenticator is certainly a plausible avenue of attack.
What You Expect
Dear DDJ,
I was pleased to read the following in Verity Stob's May 2003 column about Windows XP's StrCmpLogicalW() function: "It doesn't sort in the order that you expect; it sorts in the order that you ought to expect!" I'd like to think that this function was inspired by my article "Alphanumeric Ordering" (DDJ, October 2000)?
David Wincelberg
CPRM Redux
Dear DDJ,
I got a kick out of Jonathan Erickson's "Editorial" (DDJ, March 2001) about Content Protection for Recordable Media (CPRM) and its side effects (like preventing backup). I find the idea particularly amusing because CPRM is the floppy disk copy-protection scheme of the mid-80s, updated to modern technology. Do the proponents of CPRM remember why floppy disk copy-protection failed?
Ian Gorman
DDJ
