I've had all of fifteen minutes on the project since last time. I made it send the login challenge cookie. W00t!

If you want to know more about authentication for networked games, and what a "challenge cookie" is, read one. I'm also signed up to write a chapter in Game Programming Gems 7 on game authentication, which will likely borrow from my web page above. (As you may know, I also wrote a chapter on NAT traversal, with code, in GPG 5)

In brief, the client sends an empty login packet to the server, which the server takes as a request for a challenge. The server generates a strong random number and sends back to the client. The client computes a cryptographic hash (I'm using SHA-256) of the following items:
- user password
- challenge cookie
The client then returns a packet containing the user name and the hash to the server.
The server looks up the password in the database, and computes the same hash, using the previously emitted cookie. If the hash matches, the server sends success; if not, the server disconnects, which the client takes as a hint that the name or password was wrong.

This way, the password is never transmitted, even encrypted, over the network. Instead, the user must have set up the password beforehand (when registering, say). The draw-back is that the password must be available in cleartext for the server to retrieve, so I'll have to trust whatever IT infrastructure the servers will run on when I'm done.

I'm actually doing a ticket infrastructure, too, a la Kerberos, but I just realized that that's only useful when authentication happens on a machine different from the receiving machine. Right now, I'm having users log in anew each time they change zones (machines), so that's totally useless -- I'd better get rid of it, as it's needless complication.