Authentication Thread

[Luke-Jr]

This thread is to discuss authentication possibilities instead of hijacking other threads.
I'll keep this Post 1 updated with the latest ideas and such.

Ideas:
- GPG or SSH-like keys for auth (server sends cookie; player signs)
- IM for auth (server sends cookie via IM; player returns via game-UDP)
- If non-authenticated users are permitted on the server (including old clients), their name is wrapped in quotes
- Server admin can make a list of allowed/banned poll voters
- Server admin can make a list of players who can kick/ban
- Server admin can make a list of players who can change server settings

[Luke-Jr]

Server admins would be dependent on the master server, could not be independent without running their own master server. If the master server is compromised, well, let's just call it a single point of failure.

Yes, but if we want global user registration (and I think we want to support it for the lazy users who would otherwise choose the same password on every server anyway), there's always going to be such a single point of failure.

Not necesarilly-- using key-based auth can work around this.

Somewhere the global data has to be kept.

But servers can also cache player's public keys locally, so regulars can still play during the downtime.

Unless, of course, we use a decentral structure: have many authentication servers around (for example, a clan would run its own authentication server),

What if two authorities disagreed on who "Luke-Jr" is? I know, I suggested the idea... but it will really only work for keeping score/etc seperate, not for allowing players to be sure of who someone is.... but maybe that's not necessary?

and the globally unique ID of a player would be his authentication server ID plus his username. Then we'd have the problem of how to identify and authenticate the authentication servers... Too many levels of indirection for me to grasp right now.

Fairly simple... A user could set their ID to http://myclan.net/members/MyUsername.pgp where their public key is located.

Being a fanatic of independence, I don't like it. Not unless participation on the server admin's part is voluntary. Probably also disabled by default...

Sure thing, no central authority should be enforced (Anarchy!). The same code that authenticates the user with the master server can also be used to authenticate the user with each individual server and its local user database.

With key-based auth, there might not even need to be a difference.

Ok, it would probably be better do do this in reverse: first, the local server specific authentication, then the global one if we feel like it

Except that there need not be a difference

If we don't care to restrict the in-game nicknames (another issue altogether, IMO), we can do plain auth simply by associating ladder positions, score, etc with a public key instead of a name. The public key can even be sent by the client without sacrificing this functionality...

If we wish to have a global ladder, then we would simply need a secure way for servers to report stuff. This can be very complicated since we need to be sure nobody runs a liar-server that claims so-and-so is perfect...

If we wish to say only key 0xD53E9583 may use the name "Luke-Jr", we need to have some authority to confirm that nick "Luke-Jr" is usable by that user's public key. This shouldn't be too hard-- just allow users to upload/list their key to the website (possibly automated after key creation) and specify which in-game nicknames they wish to reserve. To work around nick-stealing, we could simply add a forum for contesting 'ownership' of a nickname.

[Z-Man]

Since this is a new thread and readers (including me) don't want to search for the other thread where you may have said this, but what exactly do you mean when you say "key based"? It's a rather broad concept. Do you mean:

-Player generates public/private key pair (like in ssh --keygen), probably with his username encoded in it
-Player publishes public key to central key server or on web page
-Variant a) Player connects to server, telling it the location of his public key. Server fetches/caches public key.
-Variant b) Player connects to server, sending the public key directly
-Server verifies that the player has the private key with a challenge/response protocol
-Server uses the public key (location) for all database entries, not the username

Advantages:
- completely decentral
- secure
Disadvantages:
- you can't play as yourself on someone else's computer without transfering your private key unless the key pair is reproducibly generated from the username and a password (not sure if I like that).

Questions and possible answers:
How do we inhibit impersonations?
Displaying the full public key location is impractical, but the server could keep track of active players; if there's one Lucifer who has played 1000 matches and a second with only 10 matches, the second Lucifer will get marked ("Lucifer", another Lucifer).

Can users change their key (say, their private key got compromised) without losing their scores?
Only when the public key is not sent directly, but fetched from a web server/authentication server, which makes the concept a bit more central.

[Luke-Jr]

Since this is a new thread and readers (including me) don't want to search for the other thread where you may have said this, but what exactly do you mean when you say "key based"?

- GPG or SSH-like keys for auth (server sends cookie; player signs)

It's a rather broad concept. Do you mean:

-Player generates public/private key pair (like in ssh --keygen), probably with his username encoded in it
-Player publishes public key to central key server or on web page
-Variant a) Player connects to server, telling it the location of his public key. Server fetches/caches public key.
-Variant b) Player connects to server, sending the public key directly
-Server verifies that the player has the private key with a challenge/response protocol
-Server uses the public key (location) for all database entries, not the username

Correct, though probably *without* the username embedded, so it can change.

Advantages:
- completely decentral
- secure
Disadvantages:
- you can't play as yourself on someone else's computer without transfering your private key unless the key pair is reproducibly generated from the username and a password (not sure if I like that).

Sure you could... generate a new key for that computer, login to website, upload new temporary key with an expiration...

Questions and possible answers:
How do we inhibit impersonations?
Displaying the full public key location is impractical, but the server could keep track of active players; if there's one Lucifer who has played 1000 matches and a second with only 10 matches, the second Lucifer will get marked ("Lucifer", another Lucifer).

Servers could, at the server admin's option, check with the central server to see if the nickname is reserved and, if so, if the key being used is acceptable.

Can users change their key (say, their private key got compromised) without losing their scores?

In the case of the centralised ladder, the scores would be associated with the user themselves and the key would only be an intermediary. This idea has other possible issues, such as possible lying servers...

Only when the public key is not sent directly, but fetched from a web server/authentication server, which makes the concept a bit more central.

But the keys can still be cached!

[Z-Man]

Aha. How would the management of player identities work, then? AA server and client know at least:
the nickname
a list of the key pairs
Some form of unique ID string (the URL to the key management server, for example)
I understand and like that part of the system, it seems simple enough.

But there's also (If I understand correctly) the username and password for some sort of nickname/key management server the game server can query for valid keys. How are those supposed to interact? What exactly should the game servers store in their score table?

But the keys can still be cached!

I guess when Lucifer and me talk about a single point of failure, we mean one single system that needs to be compromised by a hacker to take over all user IDs.

[Lucifer]

Ok, since it seems that me and z-man are on the same page with authentication either through thorough previous discussion or telepathy, maybe it would help for me to summarize and specify.

Ok, authentication in Armagetron is all about verifying that the player trying to use a certain nickname is, in fact, the person who "owns" that nickname. Anything that proceeds from there is mere convenience.

An authentication system would look like this:

1. The out of the box installation of the dedicated server should be standalone. It is not intuitive for a server administrator to setup his box to only allow authenticated users (i.e. users the server administrator has given permission to access his server) and then have him see users that he didn't allow. A default installation geared towards a centralized community system violates this requirement, and RTFM is just a crutch. Nobody reads documentation and UI should be intuitive and discoverable.

2. An account is not associated with a specific nickname, but instead should be associated with a specific player who may use multiple nicknames with the same set of authentication credentials. No consensus has been achieved on whether or not stats should default to player-based or name-based, but a consensus is achieved that both types of keying stats should be available.

3. A player should be able to use a default installation of the armagetron client to login to any server on which he has an account and play. Such a thing should be as easy for the player to do as doing the same task with an IM client, a mail client, or even just a web browser on a secure site.

4. Any authentication system that depends on a specific installation of armagetron on a specific machine for the player's credentials has pretty much been rejected. I wouldn't say we'll try to stop it, we (meaning mostly me, can't really speak for z-man on this) will try to discourage it and strongly believe the first authentication method should not be dependent in such a way.

5. Authentication should be encrypted, and registration should be encrypted, but the game itself should not be (although we've beat around the idea of supporting ssh-tunneling directly or somesuch). Where we're at now is that we have a "safe" way of sending username & password over the network (which may or may not be player-based or name-based right now, I don't recall) but no "safe" way of getting the password sent to the server the first time, for registration.

6. Ultimately, registration should be integrated so that on a default installation, armagetron would run as promiscuously as it does now, but it would take extra steps to reserve nicknames. This is a complex topic on its own with many possibilities, but the consensus right now is that a server by default should only use authentication to keep stats pure and that any other purpose of authentication should be more advanced usage.

I think that covers it all. Now back to your regularly scheduled discussion.

[Luke-Jr]

How would the management of player identities work, then?

Don't quite understand the question...

But there's also (If I understand correctly) the username and password for some sort of nickname/key management server the game server can query for valid keys. How are those supposed to interact?

There's a login to the website, which is the same as the login to these forums. Once logging in, you can manage your reserved nicks and keys.

What exactly should the game servers store in their score table?

If the server is checking if a key is valid with a central authority, it should use an ID code form that authority (forum user id?)
Else If the player has a reserved nick, use the nick
Else If the player has a public key, use the key
Else use the nick

But the keys can still be cached!

I guess when Lucifer and me talk about a single point of failure, we mean one single system that needs to be compromised by a hacker to take over all user IDs.

We could publish the public keys and it wouldn't help a hacker take over

Ok, authentication in Armagetron is all about verifying that the player trying to use a certain nickname is, in fact, the person who "owns" that nickname. Anything that proceeds from there is mere convenience.

Actually, there's 3 levels of 'authentication' (if key == player):
1. Verifying that some player is the same one that was playing before
2. Verifying that a public key being used is allowed to use the nickname they're connected as
3. Keeping a global ladder based on this

If we tie 1 & 2 together, then instead of 'key == player', we can probably get away with 'key == computer', which may be easier or better...

An authentication system would look like this:

1. The out of the box installation of the dedicated server should be standalone. It is not intuitive for a server administrator to setup his box to only allow authenticated users (i.e. users the server administrator has given permission to access his server) and then have him see users that he didn't allow. A default installation geared towards a centralized community system violates this requirement, and RTFM is just a crutch. Nobody reads documentation and UI should be intuitive and discoverable.

There is no reason not to configure the default server to authenticate against the central player database. On the same lines, neither should unregistered users (such as old clients) be denied playing by default. If a user is unregistered, we can wrap their nick in quotes.

2. An account is not associated with a specific nickname, but instead should be associated with a specific player who may use multiple nicknames with the same set of authentication credentials. No consensus has been achieved on whether or not stats should default to player-based or name-based, but a consensus is achieved that both types of keying stats should be available.

Good idea-- leave it up to the player. On the same note, should players be able to 'group' nicknames together into a single stat report?

3. A player should be able to use a default installation of the armagetron client to login to any server on which he has an account and play. Such a thing should be as easy for the player to do as doing the same task with an IM client, a mail client, or even just a web browser on a secure site.

Yep.

4. Any authentication system that depends on a specific installation of armagetron on a specific machine for the player's credentials has pretty much been rejected. I wouldn't say we'll try to stop it, we (meaning mostly me, can't really speak for z-man on this) will try to discourage it and strongly believe the first authentication method should not be dependent in such a way.

In this case, it is better to assume key == computer and give the website a new temporary key for each computer you play on. Either that, or users need to go through the hassle of copying the key file around...

5. Authentication should be encrypted, and registration should be encrypted, but the game itself should not be (although we've beat around the idea of supporting ssh-tunneling directly or somesuch). Where we're at now is that we have a "safe" way of sending username & password over the network (which may or may not be player-based or name-based right now, I don't recall) but no "safe" way of getting the password sent to the server the first time, for registration.

People are already logging into the forums via HTTP, completely unencrypted. The forum login info is the only sensitive material being sent to the central server-- it doesn't matter if someone gets the public key.

6. Ultimately, registration should be integrated so that on a default installation, armagetron would run as promiscuously as it does now, but it would take extra steps to reserve nicknames. This is a complex topic on its own with many possibilities, but the consensus right now is that a server by default should only use authentication to keep stats pure and that any other purpose of authentication should be more advanced usage.

In other words, allow unregistered nicks to connect w/o keys...

[Lucifer]

Luke, it would be really awesome if you would read everything you're replying to so I don't have to repeat myself too terribly much.

Ok, authentication in Armagetron is all about verifying that the player trying to use a certain nickname is, in fact, the person who "owns" that nickname. Anything that proceeds from there is mere convenience.

Actually, there's 3 levels of 'authentication' (if key == player):
<snip>

Actually, that was an introductory paragraph, and no coding logic was discussed, instead what you read was more like an informal specification document that summarized all the previous discussions you either weren't here when they took place, didn't read when they did take place (and you were here), or have forgotten (and were here and read them).

1. The out of the box installation of the dedicated server should be standalone. It is not intuitive for a server administrator to setup his box to only allow authenticated users (i.e. users the server administrator has given permission to access his server) and then have him see users that he didn't allow. A default installation geared towards a centralized community system violates this requirement, and RTFM is just a crutch. Nobody reads documentation and UI should be intuitive and discoverable.

There is no reason not to configure the default server to authenticate against the central player database.

One reason is underlined because I wrote it into the spec. Other reasons include the fact that making such a move would be anticompetitive monopolistic behavior, discouraging other communities from using the game and generally sending the message "If you don't join us, you have to RTFM or something". I guess it's ok as long as our code is GPL, eh?

2. An account is not associated with a specific nickname, but instead should be associated with a specific player who may use multiple nicknames with the same set of authentication credentials. No consensus has been achieved on whether or not stats should default to player-based or name-based, but a consensus is achieved that both types of keying stats should be available.

Good idea-- leave it up to the player. On the same note, should players be able to 'group' nicknames together into a single stat report?

4. Any authentication system that depends on a specific installation of armagetron on a specific machine for the player's credentials has pretty much been rejected. I wouldn't say we'll try to stop it, we (meaning mostly me, can't really speak for z-man on this) will try to discourage it and strongly believe the first authentication method should not be dependent in such a way.

In this case, it is better to assume key == computer and give the website a new temporary key for each computer you play on. Either that, or users need to go through the hassle of copying the key file around...

Obvious privacy issues. And having GPL code isn't a good enough assurance in this case.

5. Authentication should be encrypted, and registration should be encrypted, but the game itself should not be (although we've beat around the idea of supporting ssh-tunneling directly or somesuch). Where we're at now is that we have a "safe" way of sending username & password over the network (which may or may not be player-based or name-based right now, I don't recall) but no "safe" way of getting the password sent to the server the first time, for registration.

People are already logging into the forums via HTTP, completely unencrypted. The forum login info is the only sensitive material being sent to the central server-- it doesn't matter if someone gets the public key.

Please see point #1.

6. Ultimately, registration should be integrated so that on a default installation, armagetron would run as promiscuously as it does now, but it would take extra steps to reserve nicknames. This is a complex topic on its own with many possibilities, but the consensus right now is that a server by default should only use authentication to keep stats pure and that any other purpose of authentication should be more advanced usage.

In other words, allow unregistered nicks to connect w/o keys...

Yes, except your summary doesn't provide much of a spec to check your progress against.

[Luke-Jr]

Luke, it would be really awesome if you would read everything you're replying to so I don't have to repeat myself too terribly much.

I did.

1. The out of the box installation of the dedicated server should be standalone. It is not intuitive for a server administrator to setup his box to only allow authenticated users (i.e. users the server administrator has given permission to access his server) and then have him see users that he didn't allow. A default installation geared towards a centralized community system violates this requirement, and RTFM is just a crutch. Nobody reads documentation and UI should be intuitive and discoverable.

There is no reason not to configure the default server to authenticate against the central player database.

One reason is underlined because I wrote it into the spec. Other reasons include the fact that making such a move would be anticompetitive monopolistic behavior, discouraging other communities from using the game and generally sending the message "If you don't join us, you have to RTFM or something". I guess it's ok as long as our code is GPL, eh?

Then such 'other communities' should do their own builds (or even edit the URIs/hostnames in a config) to suit their preferences. There is little purpose in having an official website if the game doesn't make use of it by default.
Nothing about using the central server changes who is permitted or not on the server.

4. Any authentication system that depends on a specific installation of armagetron on a specific machine for the player's credentials has pretty much been rejected. I wouldn't say we'll try to stop it, we (meaning mostly me, can't really speak for z-man on this) will try to discourage it and strongly believe the first authentication method should not be dependent in such a way.

In this case, it is better to assume key == computer and give the website a new temporary key for each computer you play on. Either that, or users need to go through the hassle of copying the key file around...

Obvious privacy issues. And having GPL code isn't a good enough assurance in this case.

What privacy issues? They're obviously not obvious since I can't think of them.

5. Authentication should be encrypted, and registration should be encrypted, but the game itself should not be (although we've beat around the idea of supporting ssh-tunneling directly or somesuch). Where we're at now is that we have a "safe" way of sending username & password over the network (which may or may not be player-based or name-based right now, I don't recall) but no "safe" way of getting the password sent to the server the first time, for registration.

People are already logging into the forums via HTTP, completely unencrypted. The forum login info is the only sensitive material being sent to the central server-- it doesn't matter if someone gets the public key.

Please see point #1.

Irrelevant to this point, as far as I can see...

6. Ultimately, registration should be integrated so that on a default installation, armagetron would run as promiscuously as it does now, but it would take extra steps to reserve nicknames. This is a complex topic on its own with many possibilities, but the consensus right now is that a server by default should only use authentication to keep stats pure and that any other purpose of authentication should be more advanced usage.

In other words, allow unregistered nicks to connect w/o keys...

Yes, except your summary doesn't provide much of a spec to check your progress against.

What???

[Lucifer]

Then such 'other communities' should do their own builds (or even edit the URIs/hostnames in a config) to suit their preferences. There is little purpose in having an official website if the game doesn't make use of it by default.

That's not an acceptable solution. An official website serves many purposes. The dissemination of information to players, introducing the game to new players, providing support, FAQs and so forth, providing a central location for information related to the game (such as communities currently using the game). If I recall correctly, the Krawall code exists because a certain community wanted to use it. While our own community needs will drive development for the foreseeable future to a large extent (because there aren't other communities we know about right now that aren't part of this one), we should be thinking about what other people might want to do with this thing as much as is reasonable.

It's the difference between an opt-in mailing list and an opt-out mailing list.

As far as the history of this community goes, there is plenty of room to question whether or not we should be behaving in a monopolistic fashion with this community. For one thing, there are many here besides myself who would no doubt object to such a thing. Besides that, we've already felt the pain of having a single master server controlled by a guy who just disappeared for something like a year (he had already disappeared when I showed up) and there was nothing we could do about it and still retain enough association with the original armagetron that new players would know about us out here in the sticks. There has also been a number of reasons over the last year or so for people to question the viability of this port. It will take many months still, possibly years, for all of this stuff to work itself out. These are all concerns that need to be addressed in some form or other, and they're all concerns that get thrown out the window in a default installation that depends on any central server for anything, including the master server. It just so happens that we haven't yet solved the probem with the master server in that area.

Nothing about using the central server changes who is permitted or not on the server.

A default setting that uses the central server for authentication creates a situation where someone with a freshly installed server will have a server that behaves in a non-obvious non-intuitive fashion and forces the server administrator to deal with us directly right away, and if he chooses to run his server independently, he has to deal with the fact that new players are more likely to come to us and that he's not on an even playing field with us. This is the same thing as, I don't know, bundling a web browser with an OS for the purpose of preventing other web browsers from becoming competitive platforms....

In this case, it is better to assume key == computer and give the website a new temporary key for each computer you play on. Either that, or users need to go through the hassle of copying the key file around...

Obvious privacy issues. And having GPL code isn't a good enough assurance in this case.

What privacy issues? They're obviously not obvious since I can't think of them.

The fact that server admins and specifically this central server of yours will be able to track which computers people are using? That doesn't ring privacy bells in your mind? And in this case, we can't throw away the information the same way we can with IP addresses if we thought we needed to. We might not be able to identify the specific computer, but if corroborated with other information, well, developers, companies, and users have all already made the mistake of not considering potential privacy issues and we've all already been bit on the ass over it (smtp/spam for example, now it requires a big consortium working through a standards body to solve).

People are already logging into the forums via HTTP, completely unencrypted. The forum login info is the only sensitive material being sent to the central server-- it doesn't matter if someone gets the public key.

Please see point #1.

Irrelevant to this point, as far as I can see...

Point #1 was that there shouldn't be a default setting that relies on a central server for authentication, therefore it's irrelevant how people log into the forums, what's relevant is how the authentication system in-game works for independent administrators, and then we hack on our own interoperability stuff with the forums onto that and provide instructions for server administrators to hook into our global setup.

I probably forgot to mention, but that informal spec isn't just me and z-man either (and probably is biased towards my own interests). It is based on discussions that have at various times included not just a lot of players, but also ish, Tank, and a few other server admins (/dev/null I think, not sure about eggcozy). If it's missing anything those guys had thrown in, they are of course invited to add to the discussion here. It is designed to satisfy a fairly wide range of needs and has been hammered out over a large period of time, which you kinda need to accept, Luke. You can browse the old forum posts on the subject to see what other discussions have happened, most discussions on the subject have happened here as far as I know. Anyway, I'm not saying that what you want/need in an auth scheme isn't desired, and if you have anything to add to the default installation then you're welcome to, but pretty much anything that's contrary, such as adding extra hoops for a player that wants to play from his uncle's computer during christmas break, needs to be put in optional space. Optional doesn't mean "isn't included in the distribution". I've no problem including all the settings needed to hook into our own community's system in the core distribution, and when/if other communities grow up that have their own settings, we can include theirs too. If all we have to do is tell a server admin to add one line to their config file that will direct it to use our own community's setup, that's fine.

[Luke-Jr]

Then such 'other communities' should do their own builds (or even edit the URIs/hostnames in a config) to suit their preferences. There is little purpose in having an official website if the game doesn't make use of it by default.

That's not an acceptable solution.

Why not?

While our own community needs will drive development for the foreseeable future to a large extent (because there aren't other communities we know about right now that aren't part of this one), we should be thinking about what other people might want to do with this thing as much as is reasonable.

That doesn't mean defaults cannot be set to work with the official community. They can still do whatever they need with it (even without changing source!), but no-authentication-at-all helps *nobody* except singular server admin who don't wish to participate. Such singular admin can easily opt-out of the official community, but there is no reason to *encourage* or even *suggest* such activity.

It's the difference between an opt-in mailing list and an opt-out mailing list.

A better example would be opting in or opting out of in-game chatting. Of course, most people want to chat, so it is enabled by default.

As far as the history of this community goes, there is plenty of room to question whether or not we should be behaving in a monopolistic fashion with this community.

It's not monopolistic-- other communities can distribute modified configs or even packages with such configs. Likewise, there is no reason the official community cannot include our configs as defaults for our packages.

For one thing, there are many here besides myself who would no doubt object to such a thing.

Why? This seems to have the effect of saying the website is a mere website, not associated with the game itself on more than just the topic.

Besides that, we've already felt the pain of having a single master server controlled by a guy who just disappeared for something like a year (he had already disappeared when I showed up) and there was nothing we could do about it and still retain enough association with the original armagetron that new players would know about us out here in the sticks.

Before z-man disappeared, there virtually *was* no community... just a few loose players. There was also a single developer. A massive community with a team of developers is not going to fall apart that way.

There has also been a number of reasons over the last year or so for people to question the viability of this port. It will take many months still, possibly years, for all of this stuff to work itself out. These are all concerns that need to be addressed in some form or other, and they're all concerns that get thrown out the window in a default installation that depends on any central server for anything, including the master server.

And using the official website for auth does not cause problems when that website is down, other than loss of updates to the global ladder which has no solution (other than server redundancy).

It just so happens that we haven't yet solved the probem with the master server in that area.

We have redundant master servers... not much more you can do.

Nothing about using the central server changes who is permitted or not on the server.

A default setting that uses the central server for authentication creates a situation where someone with a freshly installed server will have a server that behaves in a non-obvious non-intuitive fashion

No, these defaults would be fairly good for an admin to expect and quite obvious.

and forces the server administrator to deal with us directly right away,

Why?

and if he chooses to run his server independently, he has to deal with the fact that new players are more likely to come to us and that he's not on an even playing field with us.

"come to us"?? I'm not suggesting giving server list "points" to those using official auth...

This is the same thing as, I don't know, bundling a web browser with an OS for the purpose of preventing other web browsers from becoming competitive platforms....

Not at all... it's the same thing as any other game with user registration, except that we give server admin and option to turn it off or use another authentication server.

In this case, it is better to assume key == computer and give the website a new temporary key for each computer you play on. Either that, or users need to go through the hassle of copying the key file around...

Obvious privacy issues. And having GPL code isn't a good enough assurance in this case.

What privacy issues? They're obviously not obvious since I can't think of them.

The fact that server admins and specifically this central server of yours will be able to track which computers people are using? That doesn't ring privacy bells in your mind?

Not really... you can already do that for the most part with IP addresses... o.O

And in this case, we can't throw away the information the same way we can with IP addresses if we thought we needed to.

Sure we can. If users are required to login to the forum every time they start the game, the public key can be forgotten after they stop playing. Of course, in this case I would really want an option to do a perminant key upload for, eg, home computers.

We might not be able to identify the specific computer, but if corroborated with other information, well, developers, companies, and users have all already made the mistake of not considering potential privacy issues and we've all already been bit on the ass over it (smtp/spam for example, now it requires a big consortium working through a standards body to solve).

OT: The only solution to spam is to make it not worth the trouble or to stop using SMTP.

Please see point #1.

Irrelevant to this point, as far as I can see...

Point #1 was that there shouldn't be a default setting that relies on a central server for authentication, therefore it's irrelevant how people log into the forums,

It is foolish to have default authentication anything but centralised. We can easily fix the problem with downtime by mirroring keys and having per-server caching. Worst case, the game server cannot contact and central server mirrors and doesn't have a local cache of the user keys-- assume it is a 'guest'/unreserved nickname and let them play as "nickname"

what's relevant is how the authentication system in-game works for independent administrators,

Which is a subset of the central auth

and then we hack on our own interoperability stuff with the forums onto that and provide instructions for server administrators to hook into our global setup.

Global setup will be expected as a default.

Anyway, I'm not saying that what you want/need in an auth scheme isn't desired, and if you have anything to add to the default installation then you're welcome to, but pretty much anything that's contrary, such as adding extra hoops for a player that wants to play from his uncle's computer during christmas break, needs to be put in optional space.

And none of my suggestions add these extra hoops. Yours *do*, however, add extra hoops for any players or servers wanting to participate in the official auth/ladder/etc.

If all we have to do is tell a server admin to add one line to their config file that will direct it to use our own community's setup, that's fine.

And that's all it would take.

[Lucifer]

Luke, the problem with centralized auth by default is a moral and ethical problem, not a technical problem. Where are you high-flying morals now, GatesBoy?

Bill Gates in front of the EU: "Well, they could include any media player they wanted..."
Bill Gates in front of the DOJ: "Well, they could include any browser they wanted...."

You're missing the point. The point is that it is *not* an acceptable solution to require other people to opt-out of our own community's authentication because players that are new to the game will be naturally pulled in here, and anybody who tries something different will be severely handicapped by comparison. That is anticompetitive, isn't it? Doing things that you know ahead of time will raise the barrier to entry for competition to an almost insurmountable level. Yep, looks like it to me.

The problem with tying logins to specific machines is a usability problem. However, I will stop playing on servers that want information about my computer, even if it's just a key attached to the machine. I know you don't realize how unreasonable your suggestions are to some of us out here, what do I need to say to make you realize that?

[Luke-Jr]

Luke, the problem with centralized auth by default is a moral and ethical problem, not a technical problem. Where are you high-flying morals now, GatesBoy?

There are no moral or ethical problems with a centralised auth... it is purely beneficial to the players and server admins and no trouble to disable if unwanted.

Bill Gates in front of the EU: "Well, they could include any media player they wanted..."
Bill Gates in front of the DOJ: "Well, they could include any browser they wanted...."

Completely different. The problem is not that those are included, but that they are impossible to remove.

You're missing the point. The point is that it is *not* an acceptable solution to require other people to opt-out of our own community's authentication because players that are new to the game will be naturally pulled in here, and anybody who tries something different will be severely handicapped by comparison.

Players generally go to a game's website to download it anyway... and even if that wasn't a safe assumption, there is no good reason for anyone to setup an alternate auth server so long as we play nice-- and if we stop playing nice, you can be sure all future releases will have the most unnice settings we can get away with. Also, there is no reason we couldn't have our central server delegate, eg, all nicks containing MBC (capitalised) to a server run by MicroBusCity.

That is anticompetitive, isn't it? Doing things that you know ahead of time will raise the barrier to entry for competition to an almost insurmountable level. Yep, looks like it to me.

This isn't a matter of competition. Competition would be someone forking the game along with the website... in which case they will easily change the default auth servers in the config.

The problem with tying logins to specific machines is a usability problem. However, I will stop playing on servers that want information about my computer, even if it's just a key attached to the machine.

Nothing stops you from copying that key to another computer and using it there. The only reason to have keys per-machine by default is because there is no way to have it otherwise without introducing major usability or even more centralised issues. Here are the options:
1. Store the private key on the computer and generate a new one for new computers
2. Store the private key on a server; user logs into server to download
3. Store the private key on the computer and require the player to copy this key wherever he wishes to play.
4. Generate a new private key every time you run the game and update the authentication authority.
Option 2 makes us a target to hackers and makes the game much more dependent on the server being online.
Option 3 is too complex for ordinary computer users.
Options 1 and 4 are the only real choices...

I know you don't realize how unreasonable your suggestions are to some of us out here, what do I need to say to make you realize that?

A good reason would help. I'd say its more likely I'm not explaining the idea in enough detail for anyone else to understand it-- that's fairly common with me, I think

[Lucifer]

A good reason would help. I'd say its more likely I'm not explaining the idea in enough detail for anyone else to understand it-- that's fairly common with me, I think

I'd say it's more likely you're experiencing NotInventedByLuke again and it's really starting to piss me off. It's also really starting to irritate me that you have to argue every suggestion anybody makes until we all get so sick of the argument that we'd just as soon do without. This is supposed to be a fun project, but it's no fun having to spend all your time defending something you suggested because LukeDidn'tInventIt.

Just try to look at the situation from somebody else's point of view, then look around at how other projects have dealt with similar situations from time to time. It's really not that hard to understand providing a standalone independent server configuration as the default setting.

I'm not opposed to centralized auth, I'm opposed to having it as a default on new server installations. I'm also opposed to any automatic registration system that takes personal information, but I'm not opposed to having an option to require an email address or something. See the pattern, here?

Furthermore, if your keyed solution is going to cause the problems you've cited, then you've either not even considered other implementations or it's not going to work anyway. You *must* solve the multiple-machines problem for it to work. It's in the spec.

[Luke-Jr]

A good reason would help. I'd say its more likely I'm not explaining the idea in enough detail for anyone else to understand it-- that's fairly common with me, I think

I'd say it's more likely you're experiencing NotInventedByLuke again and it's really starting to piss me off.

Well maybe you should get over the fact that there is no such thing as NotInventedByLuke. I don't care who originates an idea. I point out flaws and benefits in ideas regardless of who came up with them.

It's also really starting to irritate me that you have to argue every suggestion anybody makes until we all get so sick of the argument that we'd just as soon do without.

I see no reason not to argue for reasonable and expected defaults. Without such defaults, we might as well not have authentication support at all.

This is supposed to be a fun project, but it's no fun having to spend all your time defending something you suggested because LukeDidn'tInventIt.

Not only is the originator of the idea irrelevent, but you might note that in this debate I am on the defense, and you are the one attacking the idea.

Just try to look at the situation from somebody else's point of view, then look around at how other projects have dealt with similar situations from time to time.

Every other game (or anything along those lines) with authentication, AFAIK, has the authentication used by default. They don't implement it and require players and server admin to jump through hoops to enable it.

It's really not that hard to understand providing a standalone independent server configuration as the default setting.

No, but it mostly makes authentication pointless to implement.

I'm not opposed to centralized auth, I'm opposed to having it as a default on new server installations. I'm also opposed to any automatic registration system that takes personal information, but I'm not opposed to having an option to require an email address or something. See the pattern, here?

Nobody suggested any of the registration require personal information.

Furthermore, if your keyed solution is going to cause the problems you've cited,

except that none of them are really problems...

then you've either not even considered other implementations

I've considered both of the other suggested implementations. Hashes are easily shot down for obvious reasons we've already gone through. IM authentication could still work, but that's another dependency which isn't worth it without adding IM integration at the same time-- and I think most people agreed that it would be bloat.

or it's not going to work anyway.

Works for hundreds of people already.

You *must* solve the multiple-machines problem for it to work.

Simple:
1. You can only play from the computers you've registered with or copied your private key to.
2. You can generate a new key for each computer you play on and authorise such keys for your account.
3. You can generate a new temporary key every time you run the game and authorise that key until you are done playing.