Authentication for Players
- 1 Authentication for Players
- 1.1 What you need
- 1.2 Alternate Authentication Authorities
- 1.3 How to authenticate with a new client
- 1.4 How to authenticate with an old client
- 1.5 troubleshooting
- 1.6 Benefits
- 1.7 Security
- 1.8 Small notes for server admins
- 1.9 Design
- 1.10 How to run an Armathentication Server
- 1.11 History
Authentication for Players
Authentication is the process of proving to a server who you are. In itself, it is not terribly useful, because you usually don't get anything for it; but the server will recognize you better, it will be impossible for others to destroy your stats by picking your name in your absence, it can make tournaments less stressful by only letting registered players participate, and it provides a more secure remote server administration interface.
What you need
First, you need an account. The system is designed to be open and can accept accounts from various places; one place to get an account that works is the official forum. To the game, those accounts are identified as something that looks like an email address; a forum account would look like "<your user name>@forums". When you pick your username, you definitely should avoid non-ASCII characters (user names with those will likely change representation in the future), and it is wise to avoid the @ itself (and absolutely the "@forums", it gets added automatically), quotation marks, whitespace, and the symbols %, :, and \, an the sequence 0x. Not that the system can't handle them, but they have to be "escaped" or encoded and will look ugly, and if you ever want to ask a server administrator to give you elevated access rights, those symbols make it more difficult, leading to mistakes and you not getting your rights and missing the tournament.
What you also should definitely keep out of your username are clan tags. Clan affiliation can vary over time, and server admins are unlikely to go to the trouble to update their score tables to your new name, so you'll either use your past achievements or will have to go around with that outdated clan tag forever.
Second, what you don't need (but it's highly recommended anyway, see the notes on security below) is a new client. Yep. Even plain old Armagetron clients have the required functionality, way back to 0.2.6 and even earlier. See the history secion on why that is so.
What you also don't need is to post on the forums. Seriously. The only thing you may need to do on the forums if you have a very, very old account is to log out and log in again. If you just got the account, it should be ready to go.
Second, you need a server that supports authentication. The serverside part of the protocol was missing some bits all the time, again I refer you to the history section if you want to know details. Anyway, because the support is brand-new at the time of this writing, there are only a few servers out there that support authentication. At the time of this writing (outdated, pretty much all servers support it by now), those are:
- 1v1 Sumo Bistro
- Bugfarm Elimination Sumo
- Chico's Brake Boost Styball
- Crazy Tronners C T F
- Crazy Tronners Catfight 2
- Crazy Tronners Open Sumo
- Crazy Tronners Wild Fortress Lounge
- Crazy Tronners Wild Sumo
- Day Tripper Fortress
- Fortress Café
- Strawberry Fields
- Tag Test
- Wild Cat
Alternate Authentication Authorities
There are also other open-for-all authorities:
Some of these are tied to their forums, so all you have to do is register there.
If you only want an account that is valid on one server, talk to the administrator of that server, they can give you one.
How to authenticate with a new client
Go to your player's setup menu and scroll down; you'll find an item titled "Global ID". Enter your account name there. For a forum account, that would be "<user name>@forums". The bit before the @ typically is your username, and the bit afterwards is the host where the authentication server runs, or an abbreviation thereof ("forums" is shorthand for "forums.authentication.armagetronad.net".) If you always want to be logged in to any server you play on, enable the toggle item below that, titled "Auto Login". If you don't want that, you have to hit the "Authentication" menu item in the ingame menu. If that menu item is missing, then the server does not support authentication.
You will be prompted for a password; check your username and enter the password of your account there, then press return. On the top of the menu, you can select whether you want to store your password. See the security section for recommendations. You will be either logged in or have received an error message on the console.
Of course, you can also use the following method:
How to authenticate with an old client
Old clients (before 0.2.8) are missing the menu items where you can enter your account name and where you can trigger the login process. For them, you trigger the login procedure with chat commands. There are three variants.
- Plain "/login", will trigger authentication for a local server account.
- "/login <authority name>", will trigger login with an account at a remote authority.
In both cases, you'll have to enter your username at the password prompt, it will default to your current screen name (and due to a quirk, you will rename to the selected username after you logged in).
- The third way is to say "/login <account@authority>", this will try to log you log in as that, and preselect the username for you in the menu (in theory. This works for new clients only, sorry). Binding an instachat to that would probably not be a bad idea.
Keep in mind, that in the appearing login menu, you do not have to write the @authority part again.
Also beware, on old clients the "Abort" button disconnects you from the server.
- Make sure that you are typing your username exactly as it is at the place for authentication. For instance if you have the Player1 account on the forums it would be Player1@forums instead of player1@forums.
- If you are using an old client make sure that when you are prompted for a password that your username is correct. On older clients this will rename it to your gridname.
- Ensure that you are using the correct authority where you have an account.
Can vary. In default server settings, the only benefit you get is that the server can track you better in the hightscore tables. Other players will be able to see the account you used to log in, and that will make it harder for other players to imposter you.
One huge benefit of getting authenticated are organized tournaments. You are going to have far less problems in organized matches (clan wars and our various other competitions) if you can authenticate to the server; At least, you're going to make the server administrator running the match happy because he doesn't have to constantly ask who you are :) Getting authenticated and registered with the competition manager or server admin (they'll have to authorize you) can give you access to the team management interface. If you have sufficient rights, you can
- lock your current team by saying "/lock". No further team members may then join, unless you
- invite your teammates to play with "/invite <player name>". Invited players that are not yet playing will also receive your team's /team messages.
- kick players out or revoke invitations with "/uninvite <player name>".
- unlock the team again to the public with "/unlock".
(As safeguard against teams getting orphaned in a state where nobody can invite new members or unlock it, /invite and /unlock can always be used by those active team members that have the highest access level.)
Of course, you can get the same functionality if the server admin is present and gives you the appropriate access rights with /op, but what if the server admin is a forgetful lazy bum who forgets about scheduled matches?
There may be some servers where you have to be authenticated to chat or to play, but that is not recommended; by default, servers should be open to anyone.
Benefits on specific servers
- Chico's Brake Boost Styball : Custom Commands.
- Crazy Tronners Open Sumo : Custom Commands.
- Crazy Tronners Wild Sumo : Custom Commands.
The main weakness
Naturally, the authentication system has been designed with security in mind. The original protocol that old clients support, however, was designed to be used on a small group of trusted servers, and that makes it vulnerable to attacks from the side of the server. The one attack that is easily possible basically works like this:
- as you enter a server, the server badmin uses a modified client to play on another server.
- as you trigger the authentication procedure, the badmin does the same on the other server.
- the badmin's server relays the communication between the other server and the badmin's client to your client, and your response is routed back.
That way, the badmin will be logged on to the other server with your user account. Such a thing is called man in the middle-attack, because the badmin is the man in the middle between you and the other server.
This is the most dangerous attack on the protocol, and the modified protocol on new clients (the ones with the "Authentication" button) has protection built in; the server IP address is entangled into the communication between server and client, so that the other server would notice that your login data was not intended for it. Unless the badmin also manages to counterfeit the other server's IP address, of course, which is not impossile; however, it would usually be much easier to steal your password by other means; web forums are a pretty insecure thing, passwords of unmodded phpBB are transmitted in plain text, for example.
- If someone gets his hands on the authentication database, he will have everything he needs to imposter anyone in it. The alternative would be to transmit something in clear text so that anyone wo intercepts it can imposter you any time. - An infinite supply of throwaway remote accounts is possible; server admins have white and blacklists at their disposal against that, however.
If you have your own concerns, please voice them on the forums first. We don't want to let this section blow up with discussions.
The password menu allows you to store passwords on disk. This, of course, is insecure, as anyone who gets access to your configuration file, where the passwords are stored, will be able to use your account. The data is scrambled in a form that makes it not really feasible to extract the raw passwords, though. Anyway, our recommendation has to be not to store passwords on disk. That is especially true for users of 0.2.8.1 and earlier; there is a bug that will cause duplicate password entries to accumulate in your user.cfg.
For old clients, debug recordings where you enter passwords in the password menu are insecure, do not share them. While you can't read the password on the screen, it will be encoded in the recording and easy to extract. The same goes for the old ADMIN_PASS interface, of course.
For new clients and new servers, debug recordings are safe to share. They are cleared of the password storage data you may have in the config files, they do not contain local server accounts, and the keypresses you make while in the password menu are all replaced by "x", apart from the control keys that navigate the menu, of course.
Serverside debug recordings come with a performance penalty; as without ZThread, a recording server will make remote account lookups only between rounds.
Small notes for server admins
To run an authentication server, you need an experimental version, either 0.2.8_alpha20080209 (the server binaries for Linux and Windows have authentication built in) or later or SVN from the 0.2.8 branch:
svn co https://armagetronad.svn.sourceforge.net/svnroot/armagetronad/armagetronad/branches/0.2.8/armagetronad
Or of course, the same from bzr:
bzr co lp:armagetronad/0.2.8 armagetronad
cd armagetronad ./bootstrap.sh ./configure --enable-armathentication --disable-glout make
The extra --enable-armathentication is important, authentication is not enabled by default. It is strongly recommended that you install the library ZThread before; only with that, the requests to the remote authentication servers will be able to run in the background. Without ZThread, they will be done in the pauses between rounds. ZThread is a bit outdated and does not go well with recent versions of GCC; be sure to get the latest version (2.3.2) and to configure and build it like this (all as root):
CXXFLAGS=-fpermissive ./configure --prefix=/usr make make install ldconfig
The '--prefix=/usr' is only required on systems that don't include /usr/local in /etc/ld.so.conf.
Then, have a look at the configration file settings_authentication.cfg, it should tell you how you can configure the system.
For details of the design of the system and the protocol, check out this document.
How to run an Armathentication Server
Check it out here.
Back in 2001, when there was not yet a master server, the Krawall Gaming Network approached Z-Man with a deal. They would run a master server and a couple of permanent game servers, which were pretty rare back then, and also wanted to distribute a special client with a bit of branding. Their condition: players from Germany would only be allowed to use the master server and play on the game servers with an account at Krawall.
Work was begun, a client-server protocol was specified and implemented, but somehow, the two functions only the KGN people could implement (password check and geocheck of the IPs) were never finished.
I found no source for it, but I remember a while back Tank produced a modified client that was able to authenticate over the Krawall protocol with accounts on the forums.
Then, lots of discussion about possible ways to implement authentication were started. Things got quite heated at times, with everyone accusing everyone else that their suggested scheme would not support critical feature X or would not have security propery Y. Here are some relevant threads: