Krawall-based team management and admin logon

[Lucifer]

It's actually pretty simple. If we use the http error codes, we have to comply with the standards so that external tools besides arma that may access the page for any reason will be able to do so predictably and safely. If the http standard doesn't provide what is wanted, then we have to either use custom headers (which are supported, if ignored by other clients) or return the information in the response somehow.

Now we get into what soap/xml-rpc/etc are all about. The idea is that you send an xml-formatted request in the post data and the server returns an xml-formatted response. Not trying to push it or anything, just taking advantage of the opportunity to point it out to you, since you'd had questions previously about it. So here we would send, for example (in my own arbitrary xml thing, since xml-rpc and soap responses/requests are really complicated):

Post data:

Code: Select all

<request type="authenticate">
<user name="Lucifer" />
<password md5="luke-jrisanasshat" />  <!-- This could also say "plain=" to provide a very insecure way to authenticate -->
</request>

The server will access this data using something that looks like get_raw_post_data() or somesuch (I forget the name of the function in php, and it varies by language and api, obviously), parse it, and then determine what it is supposed to provide.

Commonly, a client-side api will provide an authentiction function that looks like this:

Code: Select all

theUser = auth.Authenticate(userName, password)
if theUser is not None:
    # I love python

Then the object referenced by "auth" will serialize the request, send it, receive the response, parse it, and return it as a python object (in this case).

So the response could look something like this:

Code: Select all

<response requesttype="auth">
<status>0</status>
</response>

Where the status field in this case would indicate an error code of some sort, and 0 is the default "user accepted" (to match up with a program returning 0 on exit to indicate Good Things). You could throw in a user-readable error message in case of failure if you'd like.

Code: Select all

<response requesttype="auth">
<status>-1</status>
<message>User has been banned for eating too many people.</message>
</response>

Ok, enough lecturing for one day.

[Z-Man]

IIRC that only reads from htdigest files which are not suitable for too many users, and which has zero chance for supporting old clients. So yeah, that would give us a high speed implementation for small user groups who can actually write htdigest files.

[Luke-Jr]

IIRC that only reads from htdigest files which are not suitable for too many users, and which has zero chance for supporting old clients. So yeah, that would give us a high speed implementation for small user groups who can actually write htdigest files.

http://httpd.apache.org/docs/2.2/mod/#A

[Z-Man]

Ah, I missed Lucifer's post, sorry. I Read it now and I have to say that this is a standard I would rather support, since it looks like it would make writing the authentication scripts even easier, a proper RPC library provided.

Yeah, I don't like the abuse of error codes; it feels wrong to return a 404 or 401 and then actually give the user the information he requested anyway. I don't think any real world problems would come from this from, say, bots crawling our authentication sites; but problems in the other direction may very well happen. For example, there may be thousands of sites out there that, by coincidence, produce valid login responses for us simply by being accessible.

In the end, I don't care much about that part of the system; it's using the good old ?method=md5&name=z-man type of argument passing. That works, and I understand it. The other stuff, while I understand it too, sounds like overkill right now to me. Can I leave this for my two co-Triumviri to figure out? You're more web development people than I am.

If you want to have a go at it, the relevant code is in nAuthentification.cpp and nKrawallPrivate.cpp (historical reasons, the division is not structurally motivated, although nKrawall.h/cpp is meant to be network code free). The first function that gets called is nLoginProcess::FetchInfoFromAuthorityRemote(), which is supposed to fill the nLoginProcess::method member variable with a good hashing method for the password, and it also sanity checks the authority URI.

The second function is nKrawall::CheckScrambledPassword(). It gets the salt and the password hash the client sent and is supposed to fill the result data structure (mostly consisting of a success flag and an error message), and it contains authority and username, which are already set from the outside; they are modifyable and changes to them will get respected.

Apart from that bit, and other small things, the branch is finished. Of course, I went a bit overboard :

There is now an actual access level system, you can have admins of various types with various rights. Every console command has a minimal access level required to activate it, all configurable, of course. Admins can recruit other admins ad-hoc via /op (they'll have a lower level, that function replaces the earlier /pickup command) and revoke that with /deop, and you can modify access levels with /promote and /demote. That's actually stuff from DedCon.

The old MD5_PASSWORD commands are also gone; instead there are just two, LOCAL_USER and LOCAL_TEAM, defining generic local accounts for users and teams. Teams, naturally, get Team Member status once they log in. Admin access rights are now handled with the USER_LEVEL command, and you can assign admin rights to players who authenticate with a password server (although I would not recommend that). You can have reserved nicknames. You can also ban players based on their authentication name, since the one you put into the UI on the client is auto-transmitted to the servers, this may even be useful

Oh yeah, the UI. The clientside changes, about the only change on the branch that has an effect if --enable-armathentication is not active: You can enter your authentication name into your player profile, and there's an auto-login switch. If active, authentication happens automatically when you enter a server, you'll be prompted for your password, of course, unless you saved it. If the switch is off, you can also log in over a new item in the ingame menu, and you can of course log in with the /login chat command, which now either accepts a full authentication username (name@ for local accounts) or an authority, in which case you'll have to enter your username at the prompt.

Anything else? Oh yeah, the other change affecting everyone, but its' not yet committed because SVN seems to be down; I unified the various commands that act on players. Specifically, the console commands now also accept partial names, like /msg does, and they all use the same function now instead of the previous three. The console commands still accept a numeric user ID, there only has been a bugfix to toInt, which would return numbers in unexpected situations. And there was some chat handling refactoring, the place was a mess. Let's hope the changes merge well. I checked a bit, and it appears the only new chat function specific to the trunk is /help.

Todo:
- authentication server white/blacklists.
- basic MITM protection
- maybe make clientside recordings safe even when you log on with them, perhaps it is possible to randomize recorded keypresses in the critical areas.
- there was a RemoveColors call somewhere that seemed wrong.
- write docs on the wiki

[Z-Man]

The todos are done. For the MITM protection, the server needs a way to know its own IP, which will usually be a task for the master servers as soon as they get updated. It's a simple addition to the login ack message. Alternatively, the server can try to guess its own IP via "SERVER_IP ALL", which does not always work, especially not for the public IP when you're behind a NAT, but that's what the master servers are for. Anyway, there are warnings when things go wrong, so I hope this will work. Only testing can tell, however.

I needed text menu items for entering the authentication name and user name that completely ignore color codes; luckily, I rediscovered the long forgotten enum rTextField::ColorMode, which, apart from turning color code detection on and off, also allows rendering text with both color codes in effect and displayed, so that you see your full text and the color effect. A cursor position bugfix later, and that mode is now the default mode for all text fields. I also made long texts in text menuitems wrap correctly while I was at it.

Since SVN is still down and we therefore have no reference version (especially, I have no current non-auth 0.2.8 checkout, here's the complete source archive. It's taken with the .svn files as a reference point, and with the autogenerated files.
http://moosnet.homelinux.net/~manuel/ar ... .8.tar.bz2
edit: yay, SVN seems back, although even slower than usual.

[Z-Man]

Well, nobody seems to care enough about how the server-to-authority protocol is supposed to look; I guess that means we're going to stick with what we have.

Since the last time we talked about it, a new variable gets passed to the scipt: query. It can have three values:

- methods. Then the script is supposed to return a list of supported methods in the form

Code: Select all

methods <method1> <method2> ...

all in one line. Can be comma separated, too, the server does not care.

- params. Then the parameter 'method' is also set to the method the server has selected, and the return is supposed to be a method-dependant list of parameters. bmd5 does not use parameters; for md5, the parameters can look like

Code: Select all

prefix <prefix>
suffix <suffix>

and those are the bits that get added to the password before the very first md5 sum is built. Missing parameters default to empty strings.

- check. Do what you did so far, check the password.

I added support for that to the more functional script that is floating around somewhere on SVN.

There is now a "reference" implementation with lots of comments in 0.2.8-auth/armagetronad/batch that shows what you're supposed to do with prefix and suffix.

We should probably make the identifier strings all case insensitive, it looks odd that the error/success return codes are in CAPS, and the rest not. I'll take care of that tomorrow.

What shall we do with the branch, now? The additions that enter default builds are bugfixes and NOP changes, mostly, apart from the support for the md5 method on the client. The remote admin interface uses different variables, and the chat functions were cleaned up (I added a couple and could not see the huge if() tree any more). Bugfarm Elimination Sumo is now running the code with authentication enabled. I'd say it's safe to merge it to 0.2.8 directly.

[Z-Man]

Buuump. In case you missed it, the last post was a call for a Triumviri decision what to do with the branch My vote goes to merge it to 0.2.8 and leave --disable-armathentication the default.

Also, Tank: could we get the forum account authentication to work with the new code? There's two things to do:
1. move http://authentication.armagetronad.net/hashauth/md5 to http://forums.authentication.armagetron ... maauth/0.1

2. make it react to ?query=methods with "methods md5 bmd5" and to ?query=params" with an empty page. Both with return code 200, of course.

[Tank Program]

Sorry about my sudden lack of input. I had lots of time to distract myself while sneaking up on exams, and not so much time now that I find myself in the middle of taking them. I'll see if I can get those modifications in.

[Z-Man]

Plan: abuse tomorrow's Ladle for extensive testing of the new code (preliminary testing in smaller groups gave no problems), then merge it back to 0.2.8 and from there to the trunk. Objections?

I'll also write up the protocol on the wiki, so we can have all security experts who are interested have a look at them without them having to dig though this and older threads.

[epsy]

Plan: abuse tomorrow's Ladle for extensive testing of the new code (preliminary testing in smaller groups gave no problems), then merge it back to 0.2.8 and from there to the trunk. Objections?

don't abuse it for "testing" score_hole, trough

[Z-Man]

Well, on that subject, I have to say...

OMG! Hey! Look! A shiny object!

]

[Z-Man]

Merging the changes back to 0.2.8 and the trunk is finished. I have to say:
LET'S NOT DO THAT AGAIN. 19 files were in conflict on the merge to the trunk.
I'm just going to do the AuthentiFIcation->authentication renaming on 0.2.8, maybe make /team chat work for spectators, then declare 0.2.8 feature complete from my point of view.

[Luke-Jr]

Open bugs on Armathentication:
- Display/preauth name is changed when you login
- Auth methods should be per player, not per authority
- - Many forum accounts are currently 'md5'-only
- - This means the initial login prompt shouldn't be delayed

[Z-Man]

Open bugs on Armathentication:
- Display/preauth name is changed when you login

It's a clientside bug, and only for clients from before the merge, as I have told you about 1000001 times before. Yes, it is annoying, but no, we cannot do anything about it, apart from getting 0.2.8.3 out faster.

- Auth methods should be per player, not per authority

No, that does not make too much sense, and would be useless anyway because users are allowed to change their username in the login prompt, which is after the hash method has been selected. Users with different authentication methods should be on different authorities.

- - Many forum accounts are currently 'md5'-only

And how is that a bug we'll be able to fix? All we can do is produce a better error message for the mbd5 users. Tank, could you see to it that they get something like "PASSWORD_UNAVAILABLE : Log out of forums.armagetronad.net and log in again with your password, please."?

- - This means the initial login prompt shouldn't be delayed

As soon as 0.2.8.3 is out, the dominant method will be md5, and that supports parameters that need to be fetched before the data for the password prompt can be sent to the client. These parameters can change over time for some login schemes, and may even be selected randomly. If you want to devise and implement a caching scheme that makes these queries unnecessary mostly without inconveniencing the users with repeated login prompts of the "sorry, our data was stale, please repeat" kind, you're welcome to do so.

[tonybbb]

so how is the update coming? Do u have any idea when 0.2.8.3 is gonna come out?