Authentication Thread

[Lucifer]

You're still missing the point, Luke.

Here's how I'm seeing it:

0. Tank plays with authentication before I ever showed up
1. Over time, numerous problems develop on servers. Server admins (mostly me and ish at this point) agree that authentication would be nice.
2. First discussions (since I showed up) on authentication. Consensus: it should be disabled by default but easy to enable, and password-based
3. Nobody does it, nobody understands the network code enough to approach the feature, the thing gets shelved.
4. Numerous off and on discussions of authentication come up, iptables is widely used instead (ish even suggested a web-based scheme using iptables but didn't like limiting ip addresses)
5. z-man reappears
6. Lucifer brings up authentication again
7. Some quiet for the most part.
8. Lucifer brings it up again
9. It gets mentioned that authentication + shaped arenas might be enough to require a version bump

I don't think any of us are opposed to a non-password implementation, and so far I'm with you on the GPG thingee, but it has to be independent of machines. It has to provide the same convenience of a password implementation, otherwise we will also need a password implementation anyway and let server admins decide which ones to support (which we already talked about, Luke, if you remember).

Once again, what I am opposed to is having a fresh server installation by default use a centralized authentication database of any type. I am also opposed to any default configuration that locks up the server from public use requiring the server admin to jump through hoops just to make it possible for someone to login and play. But that's not really the issue here, except that the side affect of having authentication of any type enabled by default in a less-than-promiscuous fashion is that default servers will be locked up. It's not a database server, after all.....

I don't see how such a default configuration makes authentication pointless in light of the wonderful history we've accumulated in the past year with people ripping and crashing servers and generally finding ways to abuse it (I couldn't use iptables to get rid of Evil Inside and his comrades when they exploited the chat bug). The fact that we haven't had it available at all has been something of a problem....

[Luke-Jr]

You're still missing the point, Luke.

Was there a point to listing the order various things happened? (just wondering!)

I don't think any of us are opposed to a non-password implementation, and so far I'm with you on the GPG thingee,

GPG would probably only work well if it was per-user keys-- I'd lean more toward some form of a RSA/DSA (SSH) key for machine/temporary keys. Either way, they're all key-based and work the same way.

but it has to be independent of machines.

Which I provided 3 solutions to. This was a good point you brought up, and I agree, but what more can I do than offer solutions?

It has to provide the same convenience of a password implementation, otherwise we will also need a password implementation anyway and let server admins decide which ones to support.

Using temporary keys is equivalent to using a password implementation, since you would need to enter your password every connection/game-run/whatever. The other solutions (and even machine-based keys) could provide more convenience than that, hence my suggestion they be kept as an option.

Once again, what I am opposed to is having a fresh server installation by default use a centralized authentication database of any type.

But why? None of your points seem to be supportive of this view, that i can tell...

I am also opposed to any default configuration that locks up the server from public use requiring the server admin to jump through hoops just to make it possible for someone to login and play.

I agree, hence why the default configuration I'm suggesting is designed to be most flexible with players.

But that's not really the issue here, except that the side affect of having authentication of any type enabled by default in a less-than-promiscuous fashion is that default servers will be locked up.

Except for the fact that authentication does not lock up the server... non-authenticated clients can still play.

It's not a database server, after all.....

Which is why it would support unauthenticated/guest players, even with authentication enabled.

I don't see how such a default configuration makes authentication pointless in light of the wonderful history we've accumulated in the past year with people ripping and crashing servers and generally finding ways to abuse it (I couldn't use iptables to get rid of Evil Inside and his comrades when they exploited the chat bug). The fact that we haven't had it available at all has been something of a problem....

If players need to jump through hoops to enable authentication, most players won't bother to do it. If servers need to jump through hoops to enable it *or* there are few players using it, they likely won't either. Thus, nobody uses authentication!

[Lucifer]

You're still missing the point, Luke.

Was there a point to listing the order various things happened? (just wondering!)

Yes, because it all boils down to this:

If players need to jump through hoops to enable authentication, most players won't bother to do it. If servers need to jump through hoops to enable it *or* there are few players using it, they likely won't either. Thus, nobody uses authentication!

Yes, server admins would do so. COnsidering the amount of effort expended by server admins to work around the fact that there isn't authentication, this is a point that can be taken until proven wrong.

I don't want players to have to do anything either, generally speaking, except to have an option that will prevent evil-doing server admins from stealing their info somehow. I'm dumping the entire load onto the server admin, here.

[Luke-Jr]

I don't want players to have to do anything either, generally speaking, except to have an option that will prevent evil-doing server admins from stealing their info somehow. I'm dumping the entire load onto the server admin, here.

In the key-based design, no server ever need be given any info usable later.

[Tank Program]

Encryption is great and all that... But it's just a game. The forums don't even use encryption! And woulnd't you consider that more important than your in game nick? There's nothing stopping me from stealing your passwords by altering phpbb. The fact is that I just don't do that because I'm a nice guy with morals. So what's wrong with following a similar authentication model to the forums. You connect to the server, enter the pass. The pass is encoded in md5 or somesuch. The server recieves it. It can a) be forwarded onto the master server for global authentication or b) be authenticated locally. No system is foolproof, but if you ask me you're making this a lot harder than it has to be, by arguing for one. Frankly, I'm tempted to implement a server that queries a copy of the forum DB. It could probably be done about a billion times faster than learning a crud load of new GPG & what not stuff, and overall is a lot simpler for admins to understand. For my part I haven't got more or less the foggiest clue what GPG is. All that sticks about authentication from this thread is that Lucifer thinks it shouldn't be enabled to a master server by default, which is perfectly fine. I still don't know what Luke thinks about this because I can't recall a clear answer.

[Tank Program]

And while I was writing that there were like 3 replies...

[Luke-Jr]

Encryption is great and all that...

Just a note-- key-based auth != encryption-for-security

But it's just a game. The forums don't even use encryption!

Exactly one point I am making

And woulnd't you consider that more important than your in game nick?

Especially since the website (which shares auth with the forums) will be used to reserve your in-game nicks...

There's nothing stopping me from stealing your passwords by altering phpbb. The fact is that I just don't do that because I'm a nice guy with morals. So what's wrong with following a similar authentication model to the forums. You connect to the server, enter the pass. The pass is encoded in md5 or somesuch. The server recieves it. It can a) be forwarded onto the master server for global authentication or b) be authenticated locally. No system is foolproof, but if you ask me you're making this a lot harder than it has to be, by arguing for one.

Using password hashes is *easily* broken since any server you connect to can simply log your hash and use it to login to other servers...

Frankly, I'm tempted to implement a server that queries a copy of the forum DB.

Which is exactly what the server default I am referring to would do-- they query the website and pull the player's authorised-public-keys.

It could probably be done about a billion times faster than learning a crud load of new GPG & what not stuff, and overall is a lot simpler for admins to understand.

No easier for admins, and it allows any random server admin to intercept the auth info easily.

For my part I haven't got more or less the foggiest clue what GPG is.

GPG is one particular key-based implementation.

All that sticks about authentication from this thread is that Lucifer thinks it shouldn't be enabled to a master server by default, which is perfectly fine. I still don't know what Luke thinks about this because I can't recall a clear answer.

I think that the default server should protect the names people have reserved by default while still allowing both registered and unregistered users to play.

[Luke-Jr]

Luci, how about this... since the entire disagreement right now is about defaults, how about we start off by simply releasing two versions of every package-- one that is vanilla-no-central-auth (Luci's pref), and one that is login-to-forum-for-central-auth-default (Luke's pref)? Eventually, the preferred set of defaults will become obvious.

[Lucifer]

Luci, how about this... since the entire disagreement right now is about defaults, how about we start off by simply releasing two versions of every package-- one that is vanilla-no-central-auth (Luci's pref), and one that is login-to-forum-for-central-auth-default (Luke's pref)? Eventually, the preferred set of defaults will become obvious.

Close, but I can do you one better.

How about we just have a different set of packages built for guru3 people and released through the forums? So the packages from the "official project" still have the neutral defaults and the people here will have the guru3 defaults. (I can think of several occasions where people here would prefer to have the neutral packages available anyway)

We only really need to worry about having platforms supported in the guru3 packages that are actually used here.

Also, there is a long-term solution, kinda. It would be nice if we could have "setting packages" that you install into the game, which follows logically from having different profiles inside the game (which we don't have right now).

[Luke-Jr]

Luci, how about this... since the entire disagreement right now is about defaults, how about we start off by simply releasing two versions of every package-- one that is vanilla-no-central-auth (Luci's pref), and one that is login-to-forum-for-central-auth-default (Luke's pref)? Eventually, the preferred set of defaults will become obvious.

Close, but I can do you one better.

Dividing the community from the project is not better.

How about we just have a different set of packages built for guru3 people and released through the forums?

The forums are central to the new website. There is no "general players" vs "guru3 people".

So the packages from the "official project" still have the neutral defaults and the people here will have the guru3 defaults.

The forum is part of the official project.

[Lucifer]

Luci, how about this... since the entire disagreement right now is about defaults, how about we start off by simply releasing two versions of every package-- one that is vanilla-no-central-auth (Luci's pref), and one that is login-to-forum-for-central-auth-default (Luke's pref)? Eventually, the preferred set of defaults will become obvious.

Close, but I can do you one better.

Dividing the community from the project is not better.

Ok, I'll play the "rewrite what you said game" if you like.

Leading by example is what we need to do, and if we're going to require other communities to build community-specific packages, then that's what we need to do.

The forum is part of the official project.

One of the problems with open source gaming is that when a community develops, it gets assimilated by the project. If new players don't like the community, they don't have a choice, they're stuck in the community the project assimilated or they can't play, except for Local Game, which isn't as much fun.

[Luke-Jr]

Leading by example is what we need to do, and if we're going to require other communities to build community-specific packages, then that's what we need to do.

There are no, and should never be, any other communities. You define GroupA as "Armagetron players"; there is no reason to define a seperate GroupB as the same. Anything more specific than "Armagetron players" applies to a subset of GroupA. GroupA is the official website/community.

The forum is part of the official project.

One of the problems with open source gaming is that when a community develops, it gets assimilated by the project. If new players don't like the community, they don't have a choice, they're stuck in the community the project assimilated or they can't play, except for Local Game, which isn't as much fun.

Nothing stops a player from joining servers with unregistered nickname, nor are registered players required to participate in the forums or such.

[Lucifer]

You know Luke, this argument is pretty worthless.

Go ahead and remove me from any authentication-related tasks, I'm not doing it now, it's not fun anymore. I've said all I have to say on the matter, now we'll see how it looks after someone does it, and then we'll see if my servers get involved or if they continue to operate independently, or if they just get shut down.

[Tank Program]

That's great Luke, but I still don't kow what this key based stuff is, and anyone who wants to run a server would have to know, and it would cause endless questions I think. Authing globally should by no means be default, because there are tons of players that are not registered on the forums. If you're still on about this has harvesting thing, auth with the master server/special authentication server and have that report to the server you just connected to that this fellow is who he says he is. Also still not fool proof. I'm inclined to say every server with their own local user database, and only approved servers can be registered globally, ie, by admins we approve, aka, us, people we trust, so we don't have to worry about this collection stuff. You're still making this way to complicated in my mind.

[Luke-Jr]

That's great Luke, but I still don't kow what this key based stuff is,

http://en.wikipedia.org/wiki/Digital_Si ... _Algorithm
http://en.wikipedia.org/wiki/Public_key_cryptography

and anyone who wants to run a server would have to know,

Not at all.

Authing globally should by no means be default, because there are tons of players that are not registered on the forums.

Authentication does not mean unregistered user cannot play.

If you're still on about this has harvesting thing, auth with the master server/special authentication server and have that report to the server you just connected to that this fellow is who he says he is.

Which is basically what key-based auth would be doing, except it would handle the central servers being down much better... not to mention working with Custom Connect, servers that don't use the central auth, etc...

I'm inclined to say every server with their own local user database, and only approved servers can be registered globally, ie, by admins we approve, aka, us, people we trust, so we don't have to worry about this collection stuff.

What collection stuff? Central auth can work without us ever needing to know the server exists.