Authentication Thread

[Lucifer]

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.

I'm not convinced this problem ever goes away, but the GPG thing should make it too impractical to phish for passwords.

In any case, just like authentication implies "weeding out evil-doing users", a global authentication server implies some mechanism in place for "weeding out evil-doing administrators".

Ack, I had intended not to use your post to launch into a new attack of a global auth server, but the more I think about it, the more I think a global auth server that defaults to let any new server in and new servers default to use it is just a bad thing.

If the auth server will have decisions made about it the same way decisions are made around here, then decisions will be made slowly and involve a lot of arguing. Meanwhile, players who are being harassed, exploited, or whatever, are caught in the middle. How will the auth server determine how to get rid of evil server admins? We've been focussed tightly on using authentication to preserve identity and deal with evil-doing players, but how will it deal with evil-doing administrators?

What happens if whoever's running the auth server does some thing or other that pisses off a segment of the player base? Can the server admins who wish take a copy of the auth database and split off from the server, or are they now locked-in to the database?

There's no selling point to players of a global auth server if anybody can join it, either. That doesn't stop people like Evil Inside from showing up and exploiting the chat code. How do you intend to determine when an evil-doing player gets banned? While I tried to ban Evil Inside, and still would, others here tried to engage him to fix other exploits. How is your global auth server going to deal with that?

A better way to achieve a global auth server is to start with a distributed system where each server only has their database, and then look for ways to combine databases and keep the system distributed. Ultimately, there is no global auth server that will be able to satisfy the diversity of opinions in the community for dealing with problems unless the community shrinks. A series of smaller groups able to establish their own rules and with a variety of ways to enforce them gives the community the most flexibility for the least amount of work.

[Z-Man]

The Nazi reference was of course a gross exaggeration...

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.

??? So you want AA players to pay us taxes? In the virtual form of taxes, say in the form of attention and praise?

Let's compare our situation to a real life one: ....
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.

What is the title of this page?
I only get myself logons to sites I really want to be a member of. I'm not logging in to MS passport. I'm not logging in at slashdot. I'm not logging in at the linux game tome. I log on to SF, guru3, ebay and occasionally my freemailers and IMs.

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.

I don't think there will be missing resources in the default installation, so the server won't be used, right?

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.

Yes, and if it contains a bit more information than required for this purpose (a way to track a machine), it's a violation of the golden rule.

One way to exploit this additional information, ...

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

Maybe, but this may just shift the problem or create new ones, at least from the perspective of a paranoid user. The session key needs to be generated and verified, generating new data gathering possibilities.

About your alternative suggestions:
1. is prone to phishing attacks in this form. Sent a user to http://S0MEAUTHSITE (note the 0 for a O) and harvest his real username.

2. Does not easily allow to set up a server that only lets in selected players (with filtering of the auth sites, this could be made possible)

3. Is about how the Krawall code currently works, only e and f work differently (and attackable as described), so I have to like it.

Lucifer: Why (provided we use an auth system where server admins can't do global evil by stealing identities and forging scores on other servers) would we bother about evil server administators? Won't the users just not play on their servers?

Can you explain how GPG (I suppose you mean cryptography in general?) can prevent phishing reliably?

I'm pretty sure the best authentication system in the world (short of a real life bouncer) can't stop a determined evil user from appearing again and again doing the same shit with new names.

I think I'm trying to gently nudge Tank into the right (use local databases first) direction with the Krawall code...

[Lucifer]

Lucifer: Why (provided we use an auth system where server admins can't do global evil by stealing identities and forging scores on other servers) would we bother about evil server administators? Won't the users just not play on their servers?

Most, sure. Some, there's room for disagreement. I'm a relativist, I guess. There's no such thing as absolute good and absolute evil, so "evil admin" in this context would be "admin not liked by whoever controls the auth server", who may be you, me, Luke, or anybody. My Evil Inside example was intended to show how server admins disagree and each do on their server what they want, generally without pressuring one another to do the same things on their servers. In the Evil Inside case, a global auth server wouldn't solve the problem, we'd still need individual filtering and stuff at the individual servers. Then we extrapolate the Evil Inside thing to include server admins... (In fact, I don't remember one server admin ever pressuring another server admin, pressure to do things usually comes from players)

For evil server admins, my only example right now is MBC, and that's only a relativity thing. I've noticed a lot of players like MBC a lot, but I've been getting a steadily increasing group of people who are disenchanted with MBC deciding they like breakfast better than busses, and the stories they tell about the admins are things I would personally consider unacceptable admin practices on my server, but it's their server and they can do what they want. I let players decide where they're going to play. But when it's time for me to share an auth server with MBC, what then?

I'm pretty sure the best authentication system in the world (short of a real life bouncer) can't stop a determined evil user from appearing again and again doing the same shit with new names.

No, the trick is to raise his cost/benefit for evil-doing, that's all. You can't build an impregnable system, and anybody who tells you they can is selling something. So instead you build a system that's harder to attack then the next system so attackers will prefer to attack the easier system.

I think I'm trying to gently nudge Tank into the right (use local databases first) direction with the Krawall code...

An observation I've been making for awhile is that server admins generally want to be independent, and when they do band together it's in small bands. I'm curious how many server admins want a global auth server when you get right down to it, I remember ish had conditions before he'd use one, and eggcozy didn't want to screw with it at all (I could be wrong about it), and /dev/null only wanted a list of evil-doing players that he could use (similar to spamcop) but he wanted his own authentication..... come to think of it, I know of only a handful of players and no server admins who have argued in favor of global authentication at any time. We want integration, generally, so we can have our fun combining stats and stuff, but we want to control our own servers at all times.

[Tank Program]

*nudged*

I'm curious as to are there any issues with using the other MD5 stuff I found in armatron. The thing with the krawall code is that it's got all that other stuff in it, so in order to use it this one send message chunk has to be commented out... But if you want a prototype of using a db, I'll also need to find out about how to make sure configure requires the correct libs... In fact, would't it be better to sorta redo the krawall code and just change it to auth by itself?

[Lucifer]

In fact, would't it be better to sorta redo the krawall code and just change it to auth by itself?

Here's how I was going to approach it. I was going to first get Krawall working more or less completely with one single type of database (flat file). Then I was going to factor it out into two separate and distinct objects, one called something like gAuthentication and one gDatabase, where gDatabase is a base class that provides basic read/write operations. Then derive from gDatabase to create gAuthDatabase which has the addition of a method that asks the question "Can I play here?" and passes the credentials as its arguments, or something like that. gAuthDatabase would be subclassed to provide implementations, and I'd factor out my original flat file code into the first subclass. In your case you'd factor out your forum-based stuff to a subclass that enables phpBB integration, and I'll probably come in later and copy it to make a more general-purpose MySQL-based implementation and then add to my com_aastats for Mambo to use it. (And then still later on, Luke could come in and make his GPG-based implementation)

So, moving along, gDatabase would be subclassed to provide implementations of various databases for various reasons, mostly stats, but also logging and stuff, with the ultimate goal of moving all file access to gDatabase's children.

(It's not a very big bonsai tree this time)

Anyway, if I ran the zoo, that's just what I'd do, said young Gerald McGrew.

[Luke-Jr]

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.

This can be solved by including some kind of server identifier in the cookie information. Not sure on the specifics it would need...

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.

The key-based method would work fine with untrusted access to user/key associations. HMAC-based would possibly be open to bruteforcing-- but we could detect that even then.

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.

Which is why either 1) the authentication server is preset or 2) the authentication server being used (URI) is displayed at the login instead of a name.

[Luke-Jr]

In any case, just like authentication implies "weeding out evil-doing users", a global authentication server implies some mechanism in place for "weeding out evil-doing administrators".

Ack, I had intended not to use your post to launch into a new attack of a global auth server, but the more I think about it, the more I think a global auth server that defaults to let any new server in and new servers default to use it is just a bad thing.

So, how exactly are evil administrators going to be aided by knowing that "this is really Lucifer, not some fake"?

If the auth server will have decisions made about it the same way decisions are made around here, then decisions will be made slowly and involve a lot of arguing. Meanwhile, players who are being harassed, exploited, or whatever, are caught in the middle.

Auth does not make it any more possible to harrass, exploit, or whatever players.

How will the auth server determine how to get rid of evil server admins?

It doesn't need to.

What happens if whoever's running the auth server does some thing or other that pisses off a segment of the player base? Can the server admins who wish take a copy of the auth database and split off from the server, or are they now locked-in to the database?

The idea of a central auth server also includes that nobody should be able to do anything that would piss someone off. The only decisions that would be involved are resolving reserved-name conflicts which can have a clear policy, similar to what z-man proposed.

There's no selling point to players of a global auth server if anybody can join it, either.

It's only an ID system.

That doesn't stop people like Evil Inside from showing up and exploiting the chat code.

Nor is it meant to. That's the job for a banlist or such.

How do you intend to determine when an evil-doing player gets banned?

The server admin decides who is banned, not the auth server. Authentication is *only* authentication, not maintaining a banlist.

While I tried to ban Evil Inside, and still would, others here tried to engage him to fix other exploits. How is your global auth server going to deal with that?

Go ahead and ban him, but it will only effect *your* servers.

A better way to achieve a global auth server is to start with a distributed system where each server only has their database, and then look for ways to combine databases and keep the system distributed.

Two of those proposals in the last post on page 3 are based on that idea.

Ultimately, there is no global auth server that will be able to satisfy the diversity of opinions in the community for dealing with problems unless the community shrinks.

Except that the auth server has *nothing* to do with opinion.

The Nazi reference was of course a gross exaggeration...

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.

??? So you want AA players to pay us taxes? In the virtual form of taxes, say in the form of attention and praise?

Um... no. I was drawing a better analogy than the nazi one.

Let's compare our situation to a real life one: ....
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.

What is the title of this page?
I only get myself logons to sites I really want to be a member of. I'm not logging in to MS passport. I'm not logging in at slashdot. I'm not logging in at the linux game tome. I log on to SF, guru3, ebay and occasionally my freemailers and IMs.

So would you prefer we change the title? Keep the forums and community seperate from the project and have the website only provide services without the community?

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.

I don't think there will be missing resources in the default installation, so the server won't be used, right?

The default install will only include a few maps, not every single one on the internet. When a player connects to a server using a non-included map, it needs to get it somewhere. Either the server must supply a URI or, if it does not, the client will try the default/central resource repository.

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.

Yes, and if it contains a bit more information than required for this purpose (a way to track a machine), it's a violation of the golden rule.

Which is a reason to NOT have it contain such information. I have already pointed out that key=session would work fine.

One way to exploit this additional information, ...

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

Maybe, but this may just shift the problem or create new ones, at least from the perspective of a paranoid user. The session key needs to be generated and verified, generating new data gathering possibilities.

You're worried about server admin finding out what your computer's random functions are? That's all it would yield...

About your alternative suggestions:
1. is prone to phishing attacks in this form. Sent a user to http://S0MEAUTHSITE (note the 0 for a O) and harvest his real username.

True... any suggestions?

2. Does not easily allow to set up a server that only lets in selected players (with filtering of the auth sites, this could be made possible)

Sure it does. None of the authentication stuff is meant to be a ban/allow list. That is completely seperate.

Can you explain how GPG (I suppose you mean cryptography in general?) can prevent phishing reliably?

If you give me an example on how someone is supposed to be phishing... Finding someone's public key is not enough to authenticate as them.

I'm pretty sure the best authentication system in the world (short of a real life bouncer) can't stop a determined evil user from appearing again and again doing the same shit with new names.

But that's not what this is meant to do.

I'm a relativist, I guess. There's no such thing as absolute good and absolute evil, so "evil admin" in this context would be "admin not liked by whoever controls the auth server", who may be you, me, Luke, or anybody.

Well, maybe that's your problem. Truth (which encompasses good and evil) is absolute, by definition.

For evil server admins, my only example right now is MBC, and that's only a relativity thing. I've noticed a lot of players like MBC a lot, but I've been getting a steadily increasing group of people who are disenchanted with MBC deciding they like breakfast better than busses, and the stories they tell about the admins are things I would personally consider unacceptable admin practices on my server, but it's their server and they can do what they want. I let players decide where they're going to play. But when it's time for me to share an auth server with MBC, what then?

Then the same players can play on both servers and be sure everyone they know is the same person. Nothing more. BTW, what supposedly bad practices are there with MBC? They sometimes change configs for a match-- something wrong with that? Only other "problems" I can tell of (and I'm a regular MBC player) are lag and not running CVS.

[Lucifer]

Ok Luke, so you're talking about doing A amount of work to achieve B% of the goals, and I'm talking about doing X amount of work to achieve Y% of the goals, where X < A and Y > B, but with few overlapping goals. Additionally, for Z amount of work, we get all of what you want (except the default settings), build a distributed system rather than a centralized system, and Z+X <= A.

What I've been suggesting (which hasn't changed in 6 months or so) has the support of 3 developers including me, where what you're suggesting has the support of 1 developer. My suggestions not just leave room for yours in some form, they imply a better system be implemented over time and can reasonably be done for aardvark. Your suggestions leave no room for question and cannot reasonably be done for aardvark, and I'm not convinced we'll see them implemented anytime in the next year anyway.

You seem to be suggesting that most server admins are in support of a global auth server but have not provided any references to support that assertion, whereas two of the developers that have so far objected manage servers that serve 3/4 of the community or so. So, where are the admins that want global auth, and how much of the community do their servers represent? Additionally, what about players? No players have chimed in, probably because they don't want to get involved in developer infighting, and I'd hate to drag people into this fight against their wills, but we're both making contrary assertions of what the community wants.

The global auth server itself falls down in the face of history on our servers, when you get right down to it. One of the few places where Swampy and I have disagreed, in fact, is in allowing a player named "Hitler". I allow that name on my server but Swampy banned it on his server. Fine, I may well be in a minority on this, but how is your auth server going to protect names that server admins want protected and allow names server admins want available? ("Osama Bin Laden" is generally considered a protected "free speech" name, along with real politicians and so forth)

Show me your cards Luke, you're so far the only one arguing in favor of global auth by default. This argument should die in the face of that, but now you kinda need to put up or shut up.

[Luke-Jr]

One of the few places where Swampy and I have disagreed, in fact, is in allowing a player named "Hitler". I allow that name on my server but Swampy banned it on his server. Fine, I may well be in a minority on this, but how is your auth server going to protect names that server admins want protected and allow names server admins want available? ("Osama Bin Laden" is generally considered a protected "free speech" name, along with real politicians and so forth)

Ban the names you don't want on your server... people who insist on using such names, whether registered or not, would still need to change their name to play.

Show me your cards Luke, you're so far the only one arguing in favor of global auth by default. This argument should die in the face of that, but now you kinda need to put up or shut up.

Your system idea is designed for a small group (or large, it doesn't matter-- it's membership-based) where mine is designed such that anyone who wants to run a server can. Mine allows using only some features and disabling others, while yours requires all or none. I seriously doubt all server admin want either "full" auth or no auth... I would be an example of an exception (running 2-3 servers), and I'm sure there are others.

[Lucifer]

Luke, I linked to previous discussions where you find not only that I want a fairly flexible system, but also scalable. Please refer to the previous discussions on the subject.

Also, I made specific requests in my last post which you have ignored. I will quote them here for your convenience:

You seem to be suggesting that most server admins are in support of a global auth server but have not provided any references to support that assertion, whereas two of the developers that have so far objected manage servers that serve 3/4 of the community or so. So, where are the admins that want global auth, and how much of the community do their servers represent? Additionally, what about players? No players have chimed in, probably because they don't want to get involved in developer infighting, and I'd hate to drag people into this fight against their wills, but we're both making contrary assertions of what the community wants.

Right now the score is 3:1 against for developers. You've shown 0 admins who want your system and want it enabled by default. Improve your score or back off.

[Luke-Jr]

I've given up trying to convince you with words; I'm going to stick to using code now.
I've begun work on a 'keyauth' branch to make it functional so it can demonstrate for itself how much better it is.

[Z-Man]

Tank: Yes, the other stuff the krawall server code does should we weeded out. AFAIR, that's sending scoring messages to the master server so it can build a global league from that (which is a bad idea in an untrusted environment), I already disabled the sending itself.
I think there are no issues with the MD5 stuff from the network code, but as you see from the copyright, I have not written it myself either.

Lucifer: Right about the refactoring. We'll even need two steps in this: a very general interface that just gets an ePlayerNetID (or similar) and the command "See if you can authenticate this guy, I don't care how". One implementation of this would be the krawall password retrieval and checking code using *another* interface to check the returned mangled password for correctness as the gDatabase you suggest.

Luke: you do that if you want to waste your time. Recall that not the feasibility of your plans and whether they *technically* work was questioned, but simply whether we want a global user database. An unbiased poll would be much better at determining that.
Edit: Of course, if your branch works fine without a central authority, we'll be happy.

[Tank Program]

The reason I didn't use the existing MD5 code is that I couldn't figure out how to make it return the nice long MD5 hash that the forums uses. But if that's possible the other stuff can be scratched.

[Z-Man]

Tank: I think this should be possible, probably the right sprintf statement is all that's required. I'll look at the output of your function and see what I can do.

[Tank Program]

Thanks.