This is a development document. You may find information about the current authentication systems on Authentication for Players.
Several possible ways of doing authentication are listed here.
Read about how we could profit from the work of others by abusing instant message systems in XMPP Based Authentication.
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. Meriton has suggested another approach: Distributed Authentification Using Digital Signatures.
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.
- 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.
How To Set Up Authentication
Read the file
settings_authentication.cfg in your Configuration Files directory for more details.
In short: One can configure the 0.3.x (perhaps even 0.2.8.x) server in a way, so that users can use their forum's user name and password for authenticating on your server. To aquire this, create a file
/etc/armagetronad-dedicated/server_info.cfg, enable GLOBAL_ID 1 and assign a USER_LEVEL <username>@forums <level>. To login, type "/login forums" when connected to the server in-game (Using the menu didn't work for me).
You can define "local users", too, if you don't want to use external sources for authentication (Or if you just have no forum account). This would require these two settings: LOCAL_USER <name> <password> and USER_LEVEL <name>@ <level>
For mid round authentication zthreads is needed, you can install the libzthread-dev package on most linux distributions, but configuring armagetron before building may require a few extra options if the zthread-config script is not installed.
./configure --disable-glout LIBS="-lZThread" CXXFLAGS="-DHAVE_LIBZTHREAD" CFLAGS="-DHAVE_LIBZTHREAD"
GLOBAL_ID 1 # Enable external authentication authorities USER_LEVEL itsme@forums 0 # Grant user "itsme" from forums.armagetronad.net "Owner" privileges # Login in-game by typing: /login forums TRUST_LAN 1 # Allow login via local network (LAN) LOCAL_USER itsme superpassword # Define username and password USER_LEVEL itsme@ 0 # Grant "Owner" privileges # Login in-game by using the Authentication menu