Authentication

From Armagetron
Revision as of 19:21, 6 March 2006 by Z-man (talk | contribs)

Several possible ways of doing authentication are listed here.

IM Based

Read about how we could profit from the work of others by abusing instant message systems in XMPP Based Authentication.

Full Blown

On the forum, a way to handle authentication with full fledged security and privacy has been worked out. It is based on public key cryptography and allows central or decentral player account management. Read about it in Key Based Authentication.

Test Balloon

Since the full blown protocol uses features not yet included in the game and is rather involved, an alternative, easier to implement scheme has been suggested. The drawback: It is vulnerable against attackers who can intercept and modify network communications. It's not that bad, being able to listen to network traffic alone is not enough. Read about it in Hash Based Authentication.

Disadvantages over key based scheme:

  • Less privacy, the authentication server is contacted on every login
  • Less security, it suffices if an attacker can intercept and take over communication between the game and authentication server to log in as anyone. In the key based scheme, the attacker needs to steal the authority's private key.
  • It does not support self-signed login where the fact that you're playing on a certain machine is taken as enough authentication.

Advantage:

  • It's so simple we should be able to supply it as a patch to 0.2.8.

What's Already There

Complete support for password verification is already built in into every client, and with the configure option --enable-krawall, server code that triggers it is activated on the server. What is missing is a function that actually retrieves the right password for a player. The test balloon would reuse it to minimize work to be done and to allow existing clients to participate.

Authentication there is handled like this:

  • The client connects to the server as usual, sending the player's data, among that the player name.
  • The server generates some random data (the salt) and sends it along with an authentication request to the client.
  • The client takes a MD5 hash of the password, appends the salt and does another MD5 checksum of the combined data (that's called scrambling, and the MD5 hash of the password is called an egg).
  • The client sends the resulted scrambled egg MD5 hash back to the server.
  • The server has done the same operation on the MD5 hash of the password from the player database (The retrieval of that is the missing bit) and compares the result with what it gets from the client. If the results match, the client is authorized to use that player name.