Authentication Thread

[Z-Man]

Luke: now great, you pissed off Lucifer. Well done. Please rethink your behavior, we all want to have fun here.

Nobody is arguing against the basic form of key based authentication, it's clearly superior to the hash based password approach that's available in the code right now. What Lucifer and me don't like is the fact that you want to tie that to the forum. You seem to be assuming way too much about our users.

Ok, alternative proposition (please read to the end before commenting):

The basic plan is the key based approach. The client generates a public/private key pair, sends the nickname and the public key to the server, server verifies that the client actually has the private key. The game server uses the key/nickname pair (dubbed KNP in the following) for all local database entries. Users of old clients or clients that disabled the key genration out of paranoia (I don't think the key generation should be disabled by default, but that's something for a later discussion.) get a dummy public key.

At this point, users already can be banned based on their KNP. Of course, they can always generate a new key, so we should make that as cumbersome as possible (have the user exit the game and delete a file manually, for example) and make sure regular users don't usually have to generate new keys manually unless the old one got compromised.

The ladder as it is now gets scrapped. Instead, the server logs which KNP kicked which other KNP's ass instead in a local database.

Now, *if* the server admin wants to have a useful ladder (a ladder of KNPs is always possible) local to his server, he installs a web based system that allows users to log in (using a regular user id/password combination, dubbed ID) and to register the KNPs they use. A tool we write can then take the local databases (using KNPs) and collapse them to a ranking of IDs. (How exactly this is supposed to work is a place for another discussion, there are lots of alternatives and options.) Alternatively, he can tell the collapsing tool to use an external database of ID to KNP mappings (i.e. a global one we maintain.), then, he won't need his own web system, but will depend on the external database. His choice.

Additionally, *if* the server admin likes, he can also tie the game server itself to a ID to KNP database (his own or an external one). Then, he can
- allow only registered users to log in
- mark unregistered users
- allow nickname registration
- everything else that you want to do ingame with user authentication

*If* we want a global ladder, we can combine the local KNP scoring databases of all or selected servers into one big global database and run the same tool on that as the individual server admins, using our global user database. Other communities or sub-communities can do the same.

If I want to play on uncle Joe's computer over the holidays, I can: Of course, I'll get a new key if I forgot to bring mine on a floppy, but I can log into the ID to KNP database servers I care about and register the new KNP to my ID. This is not required for play on servers with default settings, only if I want my scores over the holidays to count on the ranking. I can even do so *after* I return home in case I forgot my passwords to the databases. We can even think about automating this process *if* the server admin opted for the ingame ID to KNP database integration, the server could direct the client to minimize and open the database page in a web browser, for example.

I reckon this is pretty much Luke's approach, only that all operations requiring any form of ID to KNP database are delayed as far as possible and are completely optional. It supports alternative communities and sub-communities.

[Luke-Jr]

Luke: now great, you pissed off Lucifer. Well done. Please rethink your behavior, we all want to have fun here.

Not my fault. If Luc doesn't really want auth, I guess I'll need to do it.

Nobody is arguing against the basic form of key based authentication, it's clearly superior to the hash based password approach that's available in the code right now. What Lucifer and me don't like is the fact that you want to tie that to the forum. You seem to be assuming way too much about our users.

What is wrong with the official game making use the official website? We're already doing so for the master server and resource repository; authentication would be one minor addition that only has benefits.

Ok, alternative proposition (please read to the end before commenting):

The basic plan is the key based approach. The client generates a public/private key pair, sends the nickname and the public key to the server, server verifies that the client actually has the private key. The game server uses the key/nickname pair (dubbed KNP in the following) for all local database entries. Users of old clients or clients that disabled the key genration out of paranoia (I don't think the key generation should be disabled by default, but that's something for a later discussion.) get a dummy public key.

At this point, users already can be banned based on their KNP. Of course, they can always generate a new key, so we should make that as cumbersome as possible (have the user exit the game and delete a file manually, for example) and make sure regular users don't usually have to generate new keys manually unless the old one got compromised.

The ladder as it is now gets scrapped. Instead, the server logs which KNP kicked which other KNP's ass instead in a local database.

Here's the problem with user=key design: Now, players are restricted to playing only on the one computer they started on; if they want to play elsewhere, they need to copy their key with them. Many computer users (and, I'm assuming, players) don't understand directories outside of their documents directory.

Now, *if* the server admin wants to have a useful ladder (a ladder of KNPs is always possible) local to his server, he installs a web based system that allows users to log in (using a regular user id/password combination, dubbed ID) and to register the KNPs they use. A tool we write can then take the local databases (using KNPs) and collapse them to a ranking of IDs. (How exactly this is supposed to work is a place for another discussion, there are lots of alternatives and options.) Alternatively, he can tell the collapsing tool to use an external database of ID to KNP mappings (i.e. a global one we maintain.), then, he won't need his own web system, but will depend on the external database. His choice.

The local ladder wouldn't *need* the name/KNP mappings... it could just report (in game) your position based on your KNP. Web stats could just use the most-recent-played-with-name.
However, your idea later about post-playing syncing of keys would need the mapping and is yet another reason to default to using the central name/KNP mappings.

Additionally, *if* the server admin likes, he can also tie the game server itself to a ID to KNP database (his own or an external one). Then, he can
- allow only registered users to log in
- mark unregistered users
- allow nickname registration
- everything else that you want to do ingame with user authentication

My suggestion for defaults is:
- registered users can log in
- unregistered users can log in (with or without marking) with unregistered nicknames

*If* we want a global ladder, we can combine the local KNP scoring databases of all or selected servers into one big global database and run the same tool on that as the individual server admins, using our global user database. Other communities or sub-communities can do the same.

The potential problem of such a design would be baddie servers "contributing" false stats databases.

If I want to play on uncle Joe's computer over the holidays, I can: Of course, I'll get a new key if I forgot to bring mine on a floppy, but I can log into the ID to KNP database servers I care about and register the new KNP to my ID. This is not required for play on servers with default settings, only if I want my scores over the holidays to count on the ranking. I can even do so *after* I return home in case I forgot my passwords to the databases.

Nice idea for the post-playing sync. However, some possible issues:
- In most cases, this is making stuff really key=machine and {machine,...}=user; Luc brought up the problem with this as being server admins having the ability to track what computer is being used.
- While playing with an unregistered key, we would need some kind of mark to warn players that "z-man" isn't the one who is usually playing. Sure, you will be registering it with your name later, but until you do so, nobody can be sure it's really you.

We can even think about automating this process *if* the server admin opted for the ingame ID to KNP database integration, the server could direct the client to minimize and open the database page in a web browser, for example.

I was thinking more along the lines of a simple predefined HTTP protocol used for registrations and such.

I reckon this is pretty much Luke's approach, only that all operations requiring any form of ID to KNP database are delayed as far as possible and are completely optional. It supports alternative communities and sub-communities.

I see how it could make the clients independent from the website (from an auth standpoint; it would still depend on it for master server list and resources)
But, as far as I can tell, it doesn't support what I think makes best sense for default
If "reg=play;unreg=play" is to be used, the server would never be assuming any player it doesn't know is unregistered. Thus, it would never have any reason to "prompt" the user for registration. The only way to work around this, AFAIK, is to either prompt for registration when creating the key (which can happen either once per machine or per session) or to prompt for registration of unregistered players. The latter would, I'm think, piss off those who prefer to remain unregistered, since they would be prompted every time they connected to a server.

[Lucifer]

Luke: now great, you pissed off Lucifer. Well done. Please rethink your behavior, we all want to have fun here.

Not my fault. If Luc doesn't really want auth, I guess I'll need to do it.

It's exactly this kind of arrogance that makes this conversation impossible. If you want to send a "**** you" to all of us independent admins, I guess I can shut down my servers and quit wasting my time, since independent admins aren't welcome, apparently.

Is that what you're trying to say, Luke?

(Yes, there are independent administrators, and I'm one of them)

[Z-Man]

Luke: now great, you pissed off Lucifer. Well done. Please rethink your behavior, we all want to have fun here.

Not my fault. If Luc doesn't really want auth, I guess I'll need to do it.

Is is so hard to understand that someone wants non-nazi default configuration?

What is wrong with the official game making use the official website?

Think of a LAN server in a research station in antarctica. Or any LAN server for that matter. I'm tempted to move the default of TALK_TO_MASTER to 0, actually, because I'm tired of seeing 100 Unnamed Servers with default configuration on the master list (and people connecting to the test servers I start for myself).

We're already doing so for the master server and resource repository; authentication would be one minor addition that only has benefits.

Neither the master server and the resource server store any kind of personalized information, they're basically just *provide* information to the client. Plus, the resource server is not used in the default configuration, you have to put some nonincluded content in your server's resource folder first.

Here's the problem with user=key design: Now, players are restricted to playing only on the one computer they started on; if they want to play elsewhere, they need to copy their key with them. Many computer users (and, I'm assuming, players) don't understand directories outside of their documents directory.

Please reread the Uncle Joe paragraph. You *can* play, but to make the servers recognize you as you, you have to do something. With the right automation, entering your password to the KNP to ID server may be enough.

The local ladder wouldn't *need* the name/KNP mappings... it could just report (in game) your position based on your KNP.

Good idea, that's possible.

Web stats could just use the most-recent-played-with-name.
However, your idea later about post-playing syncing of keys would need the mapping and is yet another reason to default to using the central name/KNP mappings.

Well, of course A needs A. That's a tautology *If* user and server admin want to make it possible to log in from different computers and have secure collapsed stats, they'll need a user database, logins and all that stuff. But it's not required for basic operation.

My suggestion for defaults is:
- registered users can log in
- unregistered users can log in (with or without marking) with unregistered nicknames

Sensible *if* there is a distinction between registered and unregistered users on that particular server, absolutely.

*If* we want a global ladder, we can combine the local KNP scoring databases of all or selected servers into one big global database and run the same tool on that as the individual server admins, using our global user database. Other communities or sub-communities can do the same.

The potential problem of such a design would be baddie servers "contributing" false stats databases.

That's why I wrote selected. Preventing untrusted servers from reporting false stats is entirely impossible. Instead of thinking about an authentication system for trusted servers, a system where the central stats server pulls information from known good servers is clearly a simplier alternative.

- In most cases, this is making stuff really key=machine and {machine,...}=user; Luc brought up the problem with this as being server admins having the ability to track what computer is being used.

Lucifer's main objection, I think, was the central server collecting information. But you're right, we need to think through whether the additional information about the users (compared to a user ID/password based login) could become a problem. Especially if the KNPs get stored all over the place in databases...
The user should have a choice:

Users of old clients or clients that disabled the key genration out of paranoia (I don't think the key generation should be disabled by default, but that's something for a later discussion.) get a dummy public key.

- While playing with an unregistered key, we would need some kind of mark to warn players that "z-man" isn't the one who is usually playing. Sure, you will be registering it with your name later, but until you do so, nobody can be sure it's really you.

Yes, but as long as I remember the database password, I can prevent that by registering the key before or as I play (and the server can give me directions or even manage the whole process for me so I really just have to enter the password). A system where I can play as myself on any machine without bringing a key and without remembering a password is possible and already in place... But I would not call that secure

But, as far as I can tell, it doesn't support what I think makes best sense for default

Let's see, your suggested defaults as seen from the user side are

My suggestion for defaults is:
- registered users can log in
- unregistered users can log in (with or without marking) with unregistered nicknames

Perfectly possible, at least without marking Then, the server does not need the distinction between registered and unregistered users.
With marking, things get a bit more involved: The nick that's mostly used with a key is that key's main nickname and it is the one that qualifies for reservation. If two keys have the same main nickname, the most active key (with a suitable definition of active) gets the reservation, the other users get marked as unregistered.

Why would we want to prompt unknown users for registration when it's not required by the server?

[Luke-Jr]

Luke: now great, you pissed off Lucifer. Well done. Please rethink your behavior, we all want to have fun here.

Not my fault. If Luc doesn't really want auth, I guess I'll need to do it.

It's exactly this kind of arrogance that makes this conversation impossible. If you want to send a "**** you" to all of us independent admins, I guess I can shut down my servers and quit wasting my time, since independent admins aren't welcome, apparently.

The only people who would be disabling the central auth, as far as I can see any reason, would be server admins who want completely unauthenticated gameplay or those who wish to fork the project/community. Such people are hopefully in the minority and can change their configurations from the defaults. Allowing (centraly or otherwise) authentication is in no way making an affiliation with the central server any more than listing it on the master server list is.

Luke: now great, you pissed off Lucifer. Well done. Please rethink your behavior, we all want to have fun here.

Not my fault. If Luc doesn't really want auth, I guess I'll need to do it.

Is is so hard to understand that someone wants non-nazi default configuration?

Nope, but nothing I am suggesting has anything in common with nazis.

What is wrong with the official game making use the official website?

Think of a LAN server in a research station in antarctica. Or any LAN server for that matter.

Assuming that the example server does not have an internet connection, two things would happen with the proposed default config:
- Master server could not be contacted-- the game should still run anyway, right?
- Auth server could not be contacted-- all players will be assumed unregistered
So, a LAN-only server would run exactly as it does right now.

I'm tempted to move the default of TALK_TO_MASTER to 0, actually, because I'm tired of seeing 100 Unnamed Servers with default configuration on the master list (and people connecting to the test servers I start for myself).

This is a different scenario, because servers on the master list affect clients regardless of what those clients do. A bit OT, but the hundreds of default-config servers has never seemed to be a problem to me-- but maybe it's more annoying with dialup or such.

We're already doing so for the master server and resource repository; authentication would be one minor addition that only has benefits.

Neither the master server and the resource server store any kind of personalized information, they're basically just *provide* information to the client.

The resource repo requires an account on the website to upload resources. The auth server would act directly opposite, collecting keys from users and *providing* it to the servers. Neither require personal info.

Plus, the resource server is not used in the default configuration, you have to put some nonincluded content in your server's resource folder first.

The resource server, when it exists, will be used by the default configuration. If it were not, it would be *completely* pointless, not just *mostly* the auth server would be if not enabled.

Here's the problem with user=key design: Now, players are restricted to playing only on the one computer they started on; if they want to play elsewhere, they need to copy their key with them. Many computer users (and, I'm assuming, players) don't understand directories outside of their documents directory.

Please reread the Uncle Joe paragraph. You *can* play, but to make the servers recognize you as you, you have to do something. With the right automation, entering your password to the KNP to ID server may be enough.

In which case, it's not user=key, but key=machine or key=session; both of which fit well in my suggestions.

Web stats could just use the most-recent-played-with-name.
However, your idea later about post-playing syncing of keys would need the mapping and is yet another reason to default to using the central name/KNP mappings.

Well, of course A needs A. That's a tautology *If* user and server admin want to make it possible to log in from different computers and have secure collapsed stats, they'll need a user database, logins and all that stuff. But it's not required for basic operation.

I am presuming that registered users will be registered *because* they want their scores handled in such a way.

My suggestion for defaults is:
- registered users can log in
- unregistered users can log in (with or without marking) with unregistered nicknames

Sensible *if* there is a distinction between registered and unregistered users on that particular server, absolutely.

I am referring to global user registrations. If there is a reason to require a seperate registration for an individual or group of servers, that is not the majority (and therefore, best default) of situations.

*If* we want a global ladder, we can combine the local KNP scoring databases of all or selected servers into one big global database and run the same tool on that as the individual server admins, using our global user database. Other communities or sub-communities can do the same.

The potential problem of such a design would be baddie servers "contributing" false stats databases.

That's why I wrote selected. Preventing untrusted servers from reporting false stats is entirely impossible. Instead of thinking about an authentication system for trusted servers, a system where the central stats server pulls information from known good servers is clearly a simplier alternative.

That can work, but again, the global ladder can easily be kept seperate from the authentication itself. Thus, servers which authenticate (most) would not necesarilly be participating in the central ladder.

- In most cases, this is making stuff really key=machine and {machine,...}=user; Luc brought up the problem with this as being server admins having the ability to track what computer is being used.

Lucifer's main objection, I think, was the central server collecting information.

Which it doesn't, other than the needed user/key associations. Anything else would be possible entirely by coincidence and only abusable by us (in which case, if we want to be abusive we can add it into the client and not worry about the serverside, so it's a non-issue really, IMHO)

But you're right, we need to think through whether the additional information about the users (compared to a user ID/password based login) could become a problem. Especially if the KNPs get stored all over the place in databases...

The keys tell you nothing, really, except that it's the same person/machine/session that was using that key last time you saw it.

The user should have a choice:

Users of old clients or clients that disabled the key genration out of paranoia (I don't think the key generation should be disabled by default, but that's something for a later discussion.) get a dummy public key.

I'm not saying that this stuff should all be mandatory, just defaults. Of course users and admins should be able to disable it.

- While playing with an unregistered key, we would need some kind of mark to warn players that "z-man" isn't the one who is usually playing. Sure, you will be registering it with your name later, but until you do so, nobody can be sure it's really you.

Yes, but as long as I remember the database password, I can prevent that by registering the key before or as I play

*nods* part of what I was thinking

(and the server can give me directions or even manage the whole process for me so I really just have to enter the password).

The server should *not* be given passwords at any point, or it makes it very easy to compromise accounts. The server could send a (kick-based, so old clients get a message) command telling the client to authenticate with the central server first, but the client should be doing that anyway unless auth has been disabled...

A system where I can play as myself on any machine without bringing a key and without remembering a password is possible and already in place... But I would not call that secure

The design I'm suggesting would call for the user to either authenticate with the forums the first time the game is run on a computer (key=machine; has possible issues, other than security) or when the game is started (key=session)

But, as far as I can tell, it doesn't support what I think makes best sense for default

Let's see, your suggested defaults as seen from the user side are

My suggestion for defaults is:
- registered users can log in
- unregistered users can log in (with or without marking) with unregistered nicknames

Perfectly possible, at least without marking Then, the server does not need the distinction between registered and unregistered users.
With marking, things get a bit more involved: The nick that's mostly used with a key is that key's main nickname and it is the one that qualifies for reservation. If two keys have the same main nickname, the most active key (with a suitable definition of active) gets the reservation, the other users get marked as unregistered.

One slight difference in what I would suggest, though your idea could very well work:
- Allow users to choose up to _ (5?) registered nicknames.
- If two users have a collision, decide based on your 'qualifies for reservation'
- Allow clans to register certain patterns, such as "MBC", for use solely by their members; this can be done by either forwarding matching requests to an auth server run by them or by maintaining a list of their members on the central server (?)

Why would we want to prompt unknown users for registration when it's not required by the server?

Unknown users are unlikely to know about the new auth features *or* existing players on a newly installed computer:
- The majority of unknown users are likely to want to register their nick; the game suggests & allows them to register the first time they run it
- The majority of existing players, especially those installing AA on another computer, are likely to be registered.

[Lucifer]

The only people who would be disabling the central auth, as far as I can see any reason, would be server admins who want completely unauthenticated gameplay or those who wish to fork the project/community. Such people are hopefully in the minority and can change their configurations from the defaults. Allowing (centraly or otherwise) authentication is in no way making an affiliation with the central server any more than listing it on the master server list is.

Are you so infallible Luke that the reasons you dream up for why people do things must be the only possible reasons and that you can reject all other reasons?

The Breakfast group of servers has been independent for pretty much all of their lives, as far as I know. We haven't joined any global ladders (we made our own), and there's not a lot of overlap between breakfasters and people here on the forums. There is some, but by and large most of the people that play Breakfast servers don't come here, don't care about this place, and don't want to have anything to do with it. I don't know how you assume most players want to be involved here, my own experience tells me most players *don't*. I've asked around quite a bit. When Tank made his newest rankings script, I asked around on my servers and on the Swamplands (I don't recall if there was one or two Swamplands back then), and the answer I got was "No", and an occasional conditional "Yes, but only if the stats are going to be represented accurately because I don't play any of the other servers that are included by the script". When TnA asked Swampy if he wanted to become a World server, I (and I think Swampy too) tossed around the idea on the Breakfast servers and the answer was "If you do it, I'll probably stop playing here, but it's your server yadayadayadayada".

So when you make a default setting that pushes independent servers out of the mix, you're pushing Breakfast out. And when you start putting motives in other people's mouths in the face of 3 pages worth of posts on the subject, well, I don't really have anyway to describe such arrogance.

I hope the inside of your ass is as pretty as you find it, Luke, I really do, because when you finally get your head out of it, you'll see a completely different world.

[Z-Man]

Before we get hopelessly lost in details, let me just comment on the main points:

The Nazi reference was of course a gross exaggeration. The link is the central management stuff. Key to fascism/totalitarism is that the state controls and manages everything. A default central user database is a step in that direction I don't think we want to make.

Let's compare our situation to a real life one: A city. Every player is a citizen. Every server is a location to party. Some citizens prefer private parties (LAN servers or pure custom connect servers). Some citizens prefer clubs/discos to party in (public internet servers). How do you find a club? You look one up in the newspaper ads or a city guide (the master server). A good city guide has sections for different styles of clubs (goth/punk/young/old audience), our master server list is lacking those ATM.
Some clubs will offer regular customers membership ID (registered logins for us) cards for real life benefits: you don't have to wait in line, get discounts on drinks, whatever.
Imagine someone making the suggestion of introducing a citywide club membership card. It won't be accepted for several reasons:
- many club owners won't like it because they want to select their special customers themselves.
- many citizens won't like it because it puts the goths in the same basket as the punks and ravers and NO serious goth will want to be in any way associated with a raver.
Making the global registration server the default is *exactly* like installing a back door in every newly opened club (and, worse, on every house that hosts a private party) for holders of the citywide membership card and telling the club owners they can build a wall in front of it if they don't like it. To the citizens, the ID card is exactly as annoying as this "Payback" stuff (in case it does not exist where you live: it's a form of discount card where you get points for everthing you buy and get goodies from the points later): I could smack the cashier in the face every time they ask me "Do you have a Payback card?".

What has a chance, however, is several goth clubs offering a joint membership card.

About the default settings:
No connection *attempts* to the outside should be made by a server in default configuration (I changed the talk_to_master default), no matter what clients say. Even if these attempts fail on a pure LAN, they still take time and that's annoying. Likewise, a default client connecting to a default server should not make any connection attempts besides the obvious one to the server. If the resource server makes such connections *in the default installation*, it's flawed and needs a redesign.

About the similarities of my modified suggestion with yours: Yes, I explicitly stated that. The crucial difference is that in my suggestion, with some restrictions, no central authority is needed.

About privacy: The golden rule of privacy is that you should not transmit (or store) more information than absolutely required for the service you're offering. If we're offering user authentication, obviously some form of user ID needs to get transmitted. A machine specific key (and we already saw that our proposals boil down to that) is not needed. One way to exploit this additional information, of course highly constructed:
Suppose my boss gives me a company laptop so I can telecommute. I forget to remove my AA installation when I return it, my boss discovers it. He gets angry because I used the company laptop to play. I tell him I only used the installation once for testing. He takes the key and checks the ladder and sees I've been actively playing many hours with that key. Unless I can prove I've been using the same key from other computers, I'm fired. (Of course, OTOH, if I really only tested the installation once, I'll be able to prove that.)

And I second Lucifer that you're making way too many assumptions about users and server admins.

[Tank Program]

Slightly off-topic, but related. In a few short hours I have modified an armagetron client/server pair to work with the forums database. Overall it required minimal tweaking, or, I'm getting better at C++. The server queries the database and all good things. The only thing changed in the client is that it needs to be the md5 has from the database before it is sent, so I located a nice little bit of code that does that for me, popped it in so that it was changed before the client scrambled the pass per the krawall code, and away it went. I've attached a patch. Credits for the MD5 go to RSA Data Security, Inc. Have no fear about connecting to this server, and you must have registered prior to the 7th of June cause that's when the copy is from. Make sure you apply on a clean checkout. Also, you might have to tweak the engine Makefile.

Edit: The server is electricpotetial.net:4535

[Z-Man]

So, now the password is scrambled three times? Twice when you enter it and a third time when it's sent over the net?

Works fine for me. I met nemo online. How is the data queried from the user database? Would it be an option to tell server admins to install phpbb for user management? Would it support using one user management server for a set of game servers (without rsyncing the user database which is of course always an option)?

[Tank Program]

So, now the password is scrambled three times? Twice when you enter it and a third time when it's sent over the net?

If you say so, I'll believe you .

How is the data queried from the user database?

I used libmysql++ for accessing suprise suprise, a mysql server with the users database.

Would it be an option to tell server admins to install phpbb for user management?

Sure, you could tell them, but I don't know how practical it would be in the long run.

Would it support using one user management server for a set of game servers (without rsyncing the user database which is of course always an option)?

I think that you could just have every server query the same mysql server. The best thing however, would be to come up with our own PHP (or some such) user management control, and then also store stats directly in the database, which is something I think I'll take a look at soon. The one thing is that, and you may have noticed, the test server is running a dreadfully outdated version of Armagetron... Predating the binary name change... There are two reasons for this, first, was that I worked off my previous alterations to krawall stuff. Second, and more important, is that when I configured AA with --enable-krawallserver, it wasn't working for some reason. Maybe I commented out the wrong bit of krawall code, or something, but if someone could test to see if that isn't just me... If I can get the stats stuff working properly, we can have that as --enable-mysql-stats or something.

[Luke-Jr]

The only people who would be disabling the central auth, as far as I can see any reason, would be server admins who want completely unauthenticated gameplay or those who wish to fork the project/community. Such people are hopefully in the minority and can change their configurations from the defaults. Allowing (centraly or otherwise) authentication is in no way making an affiliation with the central server any more than listing it on the master server list is.

Are you so infallible Luke that the reasons you dream up for why people do things must be the only possible reasons and that you can reject all other reasons?

Nope, but nobody has given any other reasons.

The Breakfast group of servers has been independent for pretty much all of their lives, as far as I know. We haven't joined any global ladders (we made our own), and there's not a lot of overlap between breakfasters and people here on the forums. There is some, but by and large most of the people that play Breakfast servers don't come here, don't care about this place, and don't want to have anything to do with it.

Why don't Breakfast want to be part of the AA community? I was not aware of this problem, and I'm not sure why you expected me to be without being told of it.

I don't know how you assume most players want to be involved here, my own experience tells me most players *don't*. I've asked around quite a bit.

If "here" = forums, then people don't need to be involved. All that would be necessary, at most, would be registration.

So when you make a default setting that pushes independent servers out of the mix, you're pushing Breakfast out.

No default 'pushes' anyone. Configurations can always be changed.

The Nazi reference was of course a gross exaggeration. The link is the central management stuff. Key to fascism/totalitarism is that the state controls and manages everything. A default central user database is a step in that direction I don't think we want to make.

This is more like the government having control over its taxes. The two go together; there is no reason to expect the Russian government to tax US citizens or vice versa.

Let's compare our situation to a real life one: A city. Every player is a citizen. Every server is a location to party. Some citizens prefer private parties (LAN servers or pure custom connect servers). Some citizens prefer clubs/discos to party in (public internet servers). How do you find a club? You look one up in the newspaper ads or a city guide (the master server). A good city guide has sections for different styles of clubs (goth/punk/young/old audience), our master server list is lacking those ATM.
Some clubs will offer regular customers membership ID (registered logins for us) cards for real life benefits: you don't have to wait in line, get discounts on drinks, whatever.
Imagine someone making the suggestion of introducing a citywide club membership card. It won't be accepted for several reasons:
- many club owners won't like it because they want to select their special customers themselves.
- many citizens won't like it because it puts the goths in the same basket as the punks and ravers and NO serious goth will want to be in any way associated with a raver.
Making the global registration server the default is *exactly* like installing a back door in every newly opened club (and, worse, on every house that hosts a private party) for holders of the citywide membership card and telling the club owners they can build a wall in front of it if they don't like it. To the citizens, the ID card is exactly as annoying as this "Payback" stuff (in case it does not exist where you live: it's a form of discount card where you get points for everthing you buy and get goodies from the points later): I could smack the cashier in the face every time they ask me "Do you have a Payback card?".

What has a chance, however, is several goth clubs offering a joint membership card.

However, an authentication account != membership. Authentication is more like your state photo ID-- there is one central authority. Membership to a server would be a seperate list of people who are identified by their state ID.

About the default settings:
No connection *attempts* to the outside should be made by a server in default configuration (I changed the talk_to_master default), no matter what clients say. Even if these attempts fail on a pure LAN, they still take time and that's annoying. Likewise, a default client connecting to a default server should not make any connection attempts besides the obvious one to the server. If the resource server makes such connections *in the default installation*, it's flawed and needs a redesign.

The entire purpose of the resource server is to provide a default location to look for missing resources. If the server specifies its own location, that's fine... but most admin probably don't want to be bothered setting up a webserver and such, so there is a default one they can use.

About privacy: The golden rule of privacy is that you should not transmit (or store) more information than absolutely required for the service you're offering. If we're offering user authentication, obviously some form of user ID needs to get transmitted. A machine specific key (and we already saw that our proposals boil down to that) is not needed.

The key is what acts as the identification of the user to the server.

One way to exploit this additional information, of course highly constructed:
Suppose my boss gives me a company laptop so I can telecommute. I forget to remove my AA installation when I return it, my boss discovers it. He gets angry because I used the company laptop to play. I tell him I only used the installation once for testing. He takes the key and checks the ladder and sees I've been actively playing many hours with that key. Unless I can prove I've been using the same key from other computers, I'm fired. (Of course, OTOH, if I really only tested the installation once, I'll be able to prove that.)

Which is yet another example that supports using key=session instead of key=machine.

[Tank Program]

Side note: most of the dedicated players on the Tigers Network servers never visit the forums either.

[Luke-Jr]

Some other possible auth mechanisms:
1. Key-based, Server-chosen
1a. Server tells clients where to authenticate.
1b. Client displays "Authenticate with http://SOMEAUTHSITE"
1c. Client prompts for user/password
1d. Client uploads key to http://SOMEAUTHSITE
1e. Server downloads key from SOMEAUTHSITE and verifys it

2. Key-based, Player-chosen
2a. (optional) Client logins into and uploads key to their fav. site
2b. Client tells server URI of public key: http://SOMEAUTHSITE/keys/PLAYER.key
2c. Server checks site and announces that "PLAYERNAME" from "http://SOMEAUTHSITE/keys/PLAYER.key" is connecting; players can request the name/URI association at any time.

3. HMAC-based
3a. Server sends client a cookie
3b. Client sends username and MD5(cookie+password)
3c. Two possibilities:
3ca. Server chooses AuthServer
3cb. User chooses AuthServer, as in Key-based, Player-chosen
3d. Server sends username, cookie, and MD5(cookie+password) to AuthServer
3e. AuthServer processes MD5(cookie+correctpassword) and compares it to MD5(cookie+password)
3f. AuthServer says "It's good" to Server

[Lucifer]

Are you so infallible Luke that the reasons you dream up for why people do things must be the only possible reasons and that you can reject all other reasons?

Nope, but nobody has given any other reasons.

This thread has gone to 3 pages because you've been given post after post of reasons that you've just waved your hand at and rejected.

The Breakfast group of servers has been independent for pretty much all of their lives, as far as I know. We haven't joined any global ladders (we made our own), and there's not a lot of overlap between breakfasters and people here on the forums. There is some, but by and large most of the people that play Breakfast servers don't come here, don't care about this place, and don't want to have anything to do with it.

Why don't Breakfast want to be part of the AA community? I was not aware of this problem, and I'm not sure why you expected me to be without being told of it.

Ummm, probably because it's currently how the whole community is structured? So I didn't tell you for the same reason I don't tell you what color the sky is.... z-man's comparison was apt, there are bar-hoppers and regulars and occasional visitors and so forth.

I don't know how you assume most players want to be involved here, my own experience tells me most players *don't*. I've asked around quite a bit.

If "here" = forums, then people don't need to be involved. All that would be necessary, at most, would be registration.

I don't know how you assume most players want to be involved here, my own experience tells me most players *don't*. I've asked around quite a bit.

So when you make a default setting that pushes independent servers out of the mix, you're pushing Breakfast out.

No default 'pushes' anyone. Configurations can always be changed.

The purpose of a default is to provide a reasonable setting so the program doesn't bork itself when running the first time or force the user to spend a bunch of time configuring before he can play. Instead of asking "Why should we *not* do it?", we should be asking "Why should we do it?".

So justify exactly why we should do it. (For the record, I won't be using the resource server and I'm disappointed to hear that that's the 'default' solution)

[Z-Man]

Tank: I fixed the krawall stuff again. It was just not adapted of the refactorings done off late.

One thing speaks against a global user database with the krawall code (unless you did something clever to avoid it in the password retrieval code): everyone with access to the user database (everyone who can read the result of nKrawall::GetScrambledPassword()) can take the identity of anyone if he uses a modded client.

The same goes of course for anyone able to listen to the communication with the password server.

Scenario 2: Even with this flaw fixed, another exploit path stays open to the global user ID scenario: If I run a server and someone logs in to it, it can hijack his ID at this moment to log in to another server.

I think all this must have been mentioned before. So its really only acceptable to give server admins you trust access to your user database, and use an encrypted transfer protocol. And even then: Phishing for passwords is easy. Say the swampy's servers use a common user database. I set up a server with authentication and call it "Swampy's Backyard". Users log into it and will happily enter their regular swampy's password and scenario 2 kicks in.

A possible way out of this:
Mangle the password on its way from client to server with a nonrandom bit of information. (Currently, it's mangled with a random bit of data sent by the server). One possibility would be a server "key" that is unique to every server; the keys could be distributed by the master server, for example. But that makes the master server the weak link and target of attacks. Or we could use the server's IP address.

Argh, now I have to read Luke and Lucifer again...