Krawall-based team management and admin logon

[Z-Man]

Hashing the server name won't work; 1. If you custom connect, you don't know the server name, and 2. If I plan to steal logins for server X on my server, I'll name it X, too.

So basically, we want to guarantee there's no man in the middle... Not happening with a cleartext protocol.

No, we don't want to guarantee that. I want to put up at least a small obstacle against MITM attacks. Right now, we have absolutely nothing, and requiring the attacker to at least spoof an IP with a two-way connection would be a major step forward.

Oh, could that user script return 404 when the user is not found? I like meaningful error messages

[Lucifer]

Er, 404 means page not found. There's a different error for user not found, I think. I'll google it real quick.

Edit: Two choices. 401 means authentication is required for the resource requested, which is a little ambiguous here because the resource we're requesting is authentication, and you can't require authentication to receive authentication, can you?

403 means forbidden, and is pretty generic. It's probably our best bet. If we don't want to provide a public reason for why the request failed, we can use a 404 instead, but we probably want to provide a reason.

http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html

[Tank Program]

At that point, might as well use the existing subdomains:

z-man@forums.armagetronad.net
z-man@wiki.armagetronad.net

Yeah

Except that would require maintaining two copies of the software in two places it doesn't really belong.

I would suggest, tank, that we give serious thought to hacking mediawiki and phpbb to use this same authentication method.

Might be.

[Z-Man]

I don't care too much about the actual value of the return codes; nanohttp can distinguish between pages that really don't exist (where apache itself produces an error) and where the script returns a 404 error. I think of the query for a user password validation as a request for information about that user; and in a sense that does not exist, because the user does not exist, (a CMS may return 404 if it can't find a requested information, too, even if it still produces a nice error page itself) so 404 makes sense to me.

But as I said, it doesn't matter. On error, I'll make the returned data visible to the user; if the content gives the user a clue as to why authentication failed, that's fine by me. All that is important is what has to happen for a successful login: the password page needs to start with PASSWORD_OK and the return value needs to be 200.

The "leak" in ZThreads, on closer inspection, really isn't a leak. The object is cleared later on and only reported as leaky because the memory manager gets shut down before. Hmm. Maybe I can shuffle the finalization around by messing with CFLAGS. Edit: LDFLAGS, I mean. And of course it doesn't work. Shared libraries are shut down after the main program, and if we link statically, we get the usual problem that static libraries need a s strict dependency order, and sadly, that dependency order would enforce the same shutdown order as before. Well, what can I say? I disabled warnings about leaks in external libraries.

[Luke-Jr]

I would suggest, tank, that we give serious thought to hacking mediawiki and phpbb to use this same authentication method.

I'd like to see all 3 (resource uploading included) use the same distributed auth as Arma. But even then, we still have the question of what to do with the existing user accounts.

403 means forbidden, and is pretty generic. It's probably our best bet. If we don't want to provide a public reason for why the request failed, we can use a 404 instead, but we probably want to provide a reason.

10.4.4 403 Forbidden
The server understood the request, but is refusing to fulfill it. Authorization will not help and the request SHOULD NOT be repeated. If the request method was not HEAD and the server wishes to make public why the request has not been fulfilled, it SHOULD describe the reason for the refusal in the entity. If the server does not wish to make this information available to the client, the status code 404 (Not Found) can be used instead.

Fact is, authorization WILL help the request, so 403 can't be used in a standards compliant way. 400 or 404 should mean this method is not supported, so Arma would then try XMPP or whatever else.

10.4.5 404 Not Found
The server has not found anything matching the Request-URI

The Authorization header is not the Request-URI, sorry.

At that point, might as well use the existing subdomains:

z-man@forums.armagetronad.net
z-man@wiki.armagetronad.net

Yeah

Except that would require maintaining two copies of the software in two places it doesn't really belong.

Note we have $_SERVER['HTTP_HOST'], so you could setup one copy of it and use Apache config to share it across the vhosts.

Proposal on returned content format:
<fail/success> <reason code> <english reason>
so:
1 PASSWORD_OK "Password is correct."
0 PASSWORD_FAIL "Wrong password."

[Concord]

Is it feasible
to limit 1 'registered' name
per IP

I could foresee
a malcontent
locking up 100 names
or something
demonic like that

[Luke-Jr]

Globally, no. Obviously we can make such a limit, or simply delete/ban abusers on armagetronad.net auth services.

[Z-Man]

I'd like to see all 3 (resource uploading included) use the same distributed auth as Arma. But even then, we still have the question of what to do with the existing user accounts.

Merge them, if possible. The forum has the most activity and history of the three, so that should be the reference user database; if there are name conflicts, the forum account should win. If there is no way to merge a wiki account/resource upload account with the forum, delete it.

10.4.5 404 Not Found
The server has not found anything matching the Request-URI

The Authorization header is not the Request-URI, sorry.

Well, but user=<username> is part of the URI, and if the user does not exist, I would say that description matches.

Proposal on returned content format:
<fail/success> <reason code> <english reason>
so:
1 PASSWORD_OK "Password is correct."
0 PASSWORD_FAIL "Wrong password."

So no more messing with http return codes? Fine by me.

[Luke-Jr]

I'd like to see all 3 (resource uploading included) use the same distributed auth as Arma. But even then, we still have the question of what to do with the existing user accounts.

Merge them, if possible. The forum has the most activity and history of the three, so that should be the reference user database; if there are name conflicts, the forum account should win. If there is no way to merge a wiki account/resource upload account with the forum, delete it.

Instead of delete, how about contact the owner to rename it? All the databases should have associated contact info...

10.4.5 404 Not Found
The server has not found anything matching the Request-URI

The Authorization header is not the Request-URI, sorry.

Well, but user=<username> is part of the URI, and if the user does not exist, I would say that description matches.

http://SERVER/armaauth is the latest URI. The username is part of the Authorization header.

Proposal on returned content format:
<fail/success> <reason code> <english reason>
so:
1 PASSWORD_OK "Password is correct."
0 PASSWORD_FAIL "Wrong password."

So no more messing with http return codes? Fine by me.

Good point, with the HTTP return codes we can mostly ignore content and leave it for a simple user message.

200 = Auth success
401 = Auth fail
Anything else (incl 404 and 500) = ArmaAuth Unsupported

[Z-Man]

Instead of delete, how about contact the owner to rename it? All the databases should have associated contact info...

Yeah, that probably would be nicer We

http://SERVER/armaauth is the latest URI. The username is part of the Authorization header.

It is? That must be the bits I ignored in PHB mode in your latest post with the script You haven't told me yet what is so wrong about the http://SERVER/armaauth?user=test&... way of passing the info to the script.

We also need a way for the server to query the protocols available on an auth server, and a way to get additional paramenters for the protocols. How about if we add a ?query=<type> request? Right now, I can think of the following requests:

methods: gives a list of supported hash methods, no further parameters.
method_info: additional information about a particular method. One additional parameter, method=<method to query>
auth: what the script did until now.
userinfo: stored data about a user, if we find a use for such a thing.

[Luke-Jr]

http://SERVER/armaauth is the latest URI. The username is part of the Authorization header.

It is? That must be the bits I ignored in PHB mode in your latest post with the script You haven't told me yet what is so wrong about the http://SERVER/armaauth?user=test&... way of passing the info to the script.

Just standards compliance.

We also need a way for the server to query the protocols available on an auth server, and a way to get additional paramenters for the protocols. How about if we add a ?query=<type> request? Right now, I can think of the following requests:

methods: gives a list of supported hash methods, no further parameters.
method_info: additional information about a particular method. One additional parameter, method=<method to query>
auth: what the script did until now.
userinfo: stored data about a user, if we find a use for such a thing.

Right now, every auth failure includes a challenge for all supported methods. If the client doesn't support a method, it shouldn't care what fields it recognizes.

[Z-Man]

Just standards compliance.

Explain a bit more, please? RFCs are not my favorite literature, all I see is that every dynamic site out there uses parameters encoded into the URL.

Right now, every auth failure includes a challenge for all supported methods. If the client doesn't support a method, it shouldn't care what fields it recognizes.

Ah, that's not good enough If you have to fail authentication once to get the list of supported methods, then the client will have to authenticate twice. First with a random method, and then with a really supported method. Or the server will have to send out dummy failing requests before it sends the real auth request, which will look very odd in log files, files we may want to parse at one point for attempted logins.
And the fields I'm talking about are not what the client is supposed to send, it's extra information. For htdigest authentication, for example, you need to take the md5 sum of the string username:realm:password (maybe an extra : somewhere, I can't remember), some slightly smarter forum systems than phpBB may require the md5sum of password|username. Hence the md5 authentication, as implemented, supports telling the client to append and/or prepend a string to the password before taking the md5 sum. Those strings ultimately need to come from the authentication server, or we need to implement all possible combinations in the game server.

[Luke-Jr]

Just standards compliance.

Explain a bit more, please? RFCs are not my favorite literature, all I see is that every dynamic site out there uses parameters encoded into the URL.

I don't think I'm capable of explaining any better than the RFCs, unfortunately.

Right now, every auth failure includes a challenge for all supported methods. If the client doesn't support a method, it shouldn't care what fields it recognizes.

Ah, that's not good enough If you have to fail authentication once to get the list of supported methods, then the client will have to authenticate twice. First with a random method, and then with a really supported method. Or the server will have to send out dummy failing requests before it sends the real auth request, which will look very odd in log files, files we may want to parse at one point for attempted logins.

Unfortunately, that's how HTTP authentication works...
We could always append extra ? data to filter logs with, though.

And the fields I'm talking about are not what the client is supposed to send, it's extra information. For htdigest authentication, for example, you need to take the md5 sum of the string username:realm:password (maybe an extra : somewhere, I can't remember), some slightly smarter forum systems than phpBB may require the md5sum of password|username. Hence the md5 authentication, as implemented, supports telling the client to append and/or prepend a string to the password before taking the md5 sum. Those strings ultimately need to come from the authentication server, or we need to implement all possible combinations in the game server.

The auth challenge can include arbitrary fields, just like the response can.

[Z-Man]

Unfortunately, that's how HTTP authentication works...

So it's compliance to the HTTP authentication standard you're after here? We're not exactly doing HTTP authentication. We're doing a database lookup to see whether a player is who he claims to be, we don't want to ask for permission to view a web page.

Now, compliance to the HTTP standard would be nice if it gave us any real a real advantage; such an advantage may come from special libraries or applications that already give us access to relevant user databases. Would you know any libraries that provide an HTTP authentication interface to significant types of user/password databases?

[Luke-Jr]

Now, compliance to the HTTP standard would be nice if it gave us any real a real advantage; such an advantage may come from special libraries or applications that already give us access to relevant user databases. Would you know any libraries that provide an HTTP authentication interface to significant types of user/password databases?

htaccess/htpasswd would be builtin to apache