A new attempt at a social cheating solution

by Aardappel_ on 09/23/2006 08:11, 57 messages, last message: 09/27/2006 16:35, 16774 views, last view: 05/18/2024 23:40

Since taking the masterserver down, I have been thinking of new ways to combat cheating in a social rather than technological way. You have all seen my previous ideas on this topic, and I have a new, even simpler system that allows players to establish identity and trust, and admin servers accordingly, all without any central authority:

http://strlen.com/rants/trusted_communities.html

(scroll down, the new system is under "Decentralized trust").

See if you can poke any holes in this one. It is not a silver bullet, but it will bring us much closer to be able to play without cheaters. It works hand in hand with the existing mastermode (it extends it).

If all goes well we will implement this one.

   Board Index   

#1: ..

by Passa on 09/23/2006 09:58

Hmm, sounds rather complex and confusing, also makes it harder for newbies to get into the game, which is what Sauerbraten needs the most at the moment.

My other fear is it could encourage cheating more, as Sauerbraten being open source means that there is bound to be some sort of exploit someone can program to defeat the trusted community system.

But, its unique and I'm sure once I understand it more, I'll realise its simple too, considering every other feature implemented into Sauerbraten since its conception has been simple and functional.

ID harvesting sounds impractical, people know which servers to trust anyway (well the main servers)

What if, using a hacked client, someone can steal another's ID? (id assume the IDs are shared in a certain way to make this impossible?)

Also, what about the horrible case scenario that someone loses their player ID? (assuming its just a simple string of random numbers stored in a .cfg somewhere in the sauerbraten directory) its much more difficult to protect from losing it, as unlike say this forum, you cant claim it back via email verification. (while i have no doubt I wouldnt lose mine, alot of newbie players might not remember to backup their player ID etc, this could make the entire system useless if they simply start playing again with a new ID)

reply to this message

#2: ..

by CCmachine_firefox2 on 09/23/2006 11:03

seems complicated (especially for newbies) to me...

reply to this message

#3: ..

by YG2F on 09/23/2006 12:05

@_@

wow ... maybe, as Passa said, cheaters will take all of that as a new challenge ... and that would bring even more dangerous cheaters/hackers.

And they will try to do the worst just to show they successfully hacked your system ...



And yes, that would be difficult for newbies ...


If you want to go into this direction, maybe things could go a little more simple ?


My two humble naive cents :

- Players have to register using an ISP email adress (no @yahoo, no @msn, no @google etc) with their first and last name and a nickname, and has to accept a license (don\'t cheat, don\'t hack, be polite, eat your soup, etc), then you send them a unique key/code.

- to access the masterserver, the player has to provide this key/code and the nickname he registered.

- when the player wants to connect to a server, the server asks to the master-server if this player (using his IP) has provided a valid key/code and nickname. (this way, the server can\'t steal the key/code. Servers will deal only with nicknames and IP.)

- if the master-server reply yes, then, the server allows the player to play.

- if the player is a cheater, then, other players will be able to identify him/her because of his/her nickname that can\'t be changed. And the person responsible of the server will be able to find the IP thanks to the logs.

- if a lot of players complains about an other player, then, a \"moderator\" will take a fair decision. (warning, baning for days/weeks/months/years/ever, etc)

The only closed-source piece of the system would be the master-server who manages players accounts and permissions.



That would be, i think, an intermediate step between \"being nude\" and \"wearing an armour\" ...

:-]

reply to this message

#4: Maybe something simpler?

by Drakas on 09/23/2006 12:25

Hm...

I think the easiest way to do this is for each server to store clients' data.
In Unreal Tournament 2004, for playing on servers with stats you need simply to enter a username and a new password.
I thought of a bit different idea. The server generates an ID for you and the client saves the ID in their computer. Each server will have stored ids unique only for the server itself, meaning that there is no centralised place for all IDs.

Explaining clearly:

In the client, user enters a nickname (not the nickname seen in the game) and a password. An MD5 hash is generated in the client using the nickname and the password. They connect to the server.

If the server doesn't have the hash in the list, it creates a totally new hash for the user to identify upon. The hash is saved in the server's computer and then the client receives it. The client stores the server's unique id next to the hash received by the server.

Next time the client connects, they send the new hash to the server and are straight away identified as user who has already visited.

Most likely - for the stats - the server could store the first MD5 ID in their server and assign it to the generated ID.
This has one big problvem though, you cannot change the password whenever you would like.

On the other hand - cause the server is open source - the hashes could be easily stolen and used...
So the best thing is to give different data to different servers instead of having the the same ids everywhere.

reply to this message

#5: Another idea

by Drakas on 09/23/2006 12:36

Another idea... for stats!
Each server could connect to the masterserver and send the stats of each player, by their ID.
The server would have to be registered with the masterserver in order to count the stats

reply to this message

#6: ..

by CCmachine_firefox2 on 09/23/2006 13:28

about the IDs thing, could sauer use the player's system registry to store a player's ID? then cheaters would only be able to lose their rep as a cheater by edititing the registry...

reply to this message

#7: ..

by m3ep on 09/23/2006 14:03

I actually cannot believe, what Im reading.
Your "solutions" sound like Valve-Shit, Product Activation, TCPA...

So normal Players will have to give up some (or much?)
privacy and cheaters will still cheat anyway because no system
is absolutely safe. What you are trying to do is somewhat like a
fight against Terrorism - and as you can see in the real world
this fight is useless (against Terror) but limits normal,
innocent, people.

However, I won't ever support such a system so you got to play on
your own, ok.
But I encourage you to think about what you are writing.

P.S: You could provide a password for the Masterserver on the
Forum and every player will have to solve a small task like
polynomal division (instead of 7+5) to keep kiddies who out :)
(joke)

reply to this message

#8: Re: ..

by CCmachine_firefox2 on 09/23/2006 14:11, refers to #7

sorry but i have to agree with m3ep, if cheaters are clever enough to code a hack, then they are clever enough to get around this "system"...

reply to this message

#9: ..

by Eivets on 09/23/2006 14:43

I think in principle the idea is very nice. And since most of it would be hidden in the client, there is not much complexity for the user, I think.

I am not sure, if it would work, though:
You write: "So next time you are on a server, a player named Fred joins. He already appears to have the ID you generated for him, and sends it to you."

How does he find out, that you are you? First, the nickname, which is visible for everyone. Second, perhaps the global id, which is also visible for everyone. What else? Will you send him the number he assigned to you? Then he knows this number and can impersonate you, later. Nothing more? Then he needs to send his number you assigned to him. Same problem, different direction. Maybe I misunderstood something...

This is not unsolvable, though: When you saw the nickname and global id (just a random number he generated, I think) you think you know who he is. You just have to prove it. So now you send him a random number. He sends back an MD5 hash over the following:
- the id he sent to you the first time you saw him
- the id you sent to him the first time you saw him
- the random number
- another random number he generated just for this occasion

He sends back the MD5 and the new random number.

On receiving, you can calculate the MD5 which noone else can do. If it is the same as his, you have proven that he is who he claims to be.

The impersonator never sees the id you assigned to him nor the id the real fred sent to you. And because of the two random numbers he cannot use a replay attack...

reply to this message

#10: Ummm...

by eihrul on 09/23/2006 16:44

People are talking about issues as if me and Aard have not discussed all this crap already. There is no such thing as a fool-proof solution.

We do not want to deal with centralized authentication. That is WAY more complicated than this, and creates way more support issues for us. In reality, you are far safer backing up your own identity than having us do it for you. Our hard drive crashes? Oops, thousands of identityies are gone. Someone hacks our central server? They can steal many thousands of identities all at once. The best some random hacker can do in this system is prey on an isolated person, and only with respect to the players who happen to be on at the time, not future players.

The point is to give you a more viable way to recognize players that won't cause you trouble, so if needed, you can limit games to only such people.

New players get no less screwed over than they do now with people running around crashing clients remotely, and now we have countless people posting on the forum asking why the game is crashing all over the place on them. New players are basically fucked over anyway as is. We're merely giving them a way to escape all this crap as they become more informed about the game.

In addition to this, we're also considering implementing a global blacklist just as a "big red button" last resort. The intended usage is blocking whole ISPs, not just one IP, so this would be a rather extreme measure.

reply to this message

#11: ..

by Teddy on 09/23/2006 17:05

I think it could be as simple as the server asking if you want to let this player join, but letting you ask the player some questions before excepting his request to join.

reply to this message

#12: Re: ..

by eihrul on 09/23/2006 17:37, refers to #9

I don't like the fact that in that sort of scheme you still have to send the initial ID unencrypted. A public key system would be far better.

reply to this message

#13: Re: ..

by eihrul on 09/23/2006 17:54, refers to #12

In fact, the more I think about it, rather than sending out unique ids you assign to the play, it might be better to do public key crypto whole hog, i.e.:

Bob is on server playing. Fred connects. Bob encrypts random value with Fred's public key and sends to Fred. Fred decrypts with private key that only he knows. He reencrypts the same random value with Bob's public key, and sends it back. Bob decrypts the reponse with his private key that, again, only he knows. If the response decrypts back to the original random value he sent out, Bob knows everything is A-OK and Fred's legit.

Whether Bob is legit is irrelevant, since the burden of proof is on Fred, the guy newly connecting to the server. And neither Bob nor Fred nor the server can easily figure out the private keys of Bob or Fred, subject to the normal difficulty of doing so in public key crypto.

This is cool because the only substantial part of identity you need to store is your private key, and the public key you give out to everyone else.

I just need to see what public key crypto algorithms are feasible to implement and use for this, if there are any at all.

reply to this message

#14: Re: ..

by Eivets on 09/23/2006 18:51, refers to #13

What you say is true. The person operating the server can grab ids. How much of a problem that is actually, is a question. For logging into an homebanking system, I would not choose this solution. For sauerbraten, it might be okay...

I did not propose public key stuff, because you might run into crypto export restrictions...

Anyway, if you go for this, you can use the tomcrypt library. It\'s free (public domain) contains virtually all encryption stuff including RSA and is nicely done. I used it successfully for a number of projects.

reply to this message

#15: Re: ..

by eihrul on 09/23/2006 18:57, refers to #14

Well, the public key has the advantage that the amount of info that comprises your identity is much smaller and easier to recover should you lose it in some "accident".

As for export restrictions, the crypto only needs to be relatively weak. Nothing strong enough that we'd run into those.

And well, as has been said before, most libraries tend to do waaay too much and end up being larger than the whole of Sauerbraten itself. I'd rather just implement a specialized algorithm for what we need.

reply to this message

#16: ..

by sinsky on 09/23/2006 19:11

I think the silver bullet could be allowing people to run servers with custom source code. The masterserver list should not be removed, imho.

reply to this message

#17: Re: ..

by Eivets on 09/23/2006 20:47, refers to #15

Sure, I'm in favor of public key algorithms. But I also have no problem with export restrictions.

For the size of the library: A crypto library would have to be really huge to have real influence on the 100 MB sauerbraten download ;-) Also, since tomcrypt public domain, you can even extract only the source files that you need.

Anyway, have fun...

reply to this message

#18: Viva la wikipedia!

by eihrul on 09/23/2006 22:20

http://en.wikipedia.org/wiki/Tiny_Encryption_Algorithm
http://en.wikipedia.org/wiki/XTEA

I think we have ourselves a winner. Sure, it has weaknesses, but damn is it small and simple. ;)

reply to this message

#19: Re: Viva la wikipedia!

by eihrul on 09/23/2006 22:35, refers to #18

Doh, it's symmetric only. Live and learn. :(

reply to this message

#20: Re: Viva la wikipedia!

by Eivets on 09/23/2006 22:43, refers to #18

Aeeh, don't want to poop at your party, but this is a symetric cipher, which is not exactly suited for public key,
I think :-(

All public key encryptions I know of require mathematics with huge numbers, which is not really trivial to implement.

reply to this message

   Board Index