Take the 2-minute tour ×
Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.

I wish to setup a room-based multilayer game model where players may host matches and serve as host (IE the server with authoritative power). I wish to host a master server which tracks player's items, rank, cash, exp, etc.

In such a model, how can I prevent someone that is hosting a game (with a modified server) from spoofing the master server with invalid match results, thus gaining exp, money or rankings.

Thanks. -Cody

Even shorter generic answer: you can't. As soon as code executes on a system not under your control, someone can hack it somehow, like for instance running a thousand matches and only reporting those with favorable outcomes. –  Jari Komppa Nov 30 '12 at 12:59
I agree with @JariKomppa. Also, there is no need to sign your posts. –  jco Nov 30 '12 at 15:02
@Cody: I've given two answers below, based on different interpretations of your question. Could you please let me know which one (if either) is closer to what you wanted to ask? –  Ilmari Karonen Nov 30 '12 at 23:46

3 Answers 3

up vote 4 down vote accepted

It's been pointed out that my previous answer may have been based on a misunderstanding of what you meant by "spoofing". (If so, please let me know and I'll delete it.)

If what you want to prevent is the game servers sending bogus data to the master server, then — as Jari Komppa notes — that's generally impossible to prevent completely. In fact, it's simply a variant of the classic multiplayer cheating prevention problem, except with the intermediate servers rather than the clients being the ones suspected of cheating. Many of the same techniques used for traditional cheating prevention could work here too, but as usual, none of them are completely foolproof.

That said, there are some things you could do that would specifically help against cheating servers. One of them would be to have each player in a match separately contact the master server and confirm that they're participating in that match. (You'll probably want to do that before the match begins, so that you can make sure everyone agrees who the participants are and so that nobody's tempted to claim they didn't participate in a match they lost. You could use digital signatures to defer that, though; essentially, you could have every player in a match sign a message saying "I'm player X and I'm participating in match M on server S at time T with players Y, Z and W." and send it to the game server, which can later relay it to the master server.) That way, you can at least ensure that a cheating server can't affect the rankings of any player who doesn't actually play on that server.

This is particularly useful if you're using something like Elo ratings where player ranking mostly depends on their relative performance. Sure, someone running a bogus server might still create a bunch of fake accounts and submit results saying that their own account beat the fake ones, but with a relative ranking system, all that will do is make the cheater's account rank slightly above the fakes (which in turn will have rock bottom ratings).

Another obvious thing to do to discourage cheating is to let players verify their match results directly from the master server. If a player wins a match on a new server, but the results sent to the master server say that they lost (or if the results are never sent at all), that will let them know that something fishy is going on. Hopefully, at that point they'll either report the server for cheating, or at least vote with their feet and never play on that server again.

In fact, you could make this automatic: after each game, once the results have been sent to the master server, have the clients fetch them back from the master server and compare them to how the client thinks the game ended. If there's a mismatch, report it both to the player (so that they'll know something's wrong) and to the master server (so that you can detect cheating servers). Of course, as the operator of the master server, you'll then need to decide who's lying — the server or the player — but hopefully in most cases that will be fairly obvious from the pattern of reports.

Thanks so much Ilmari, both answers were fantastic (please do keep them around). Sorry for the delay, I got sidetracked. -Cody –  Cody Smith Dec 7 '12 at 19:21

Note: This answer may be based on a misunderstanding of the question — see comments below.

Short generic answer: use digital signatures.

Specifically, the master server should have a private key for a suitable digital signature scheme (RSA, DSA, ECDSA, etc.) and should somehow securely relay its public key to all the clients. Then the server can sign any data it sends to clients with the private key (or possibly use it to negotiate a shared secret usable for symmetrically encrypting and/or authenticating communications between it and that particular client) and the client can use the public key to verify that the signature has been generated by the server.

Of course, your next problem is distributing the public key so that a rogue server can't spoof that and substitute its own public key. That might not be so hard if you can do it in advance (e.g. distributing the key along with the game executable), but it gets tricky if you have to do it later, for example because the identity of the master server is not known in advance. One standard solution is to distribute some other public key (whose corresponding private key is known only to you) in advance to all the clients, and then sign the message containing the master server's public key with that other key before broadcasting it.

In fact, you could even extend such signature chains further — say, have one super-secret master private key, which is kept locked in a safe somewhere and whose public key is known to all clients, and another "daily use" private key which is used to actually sign the server keys, and whose public key is itself signed with the super-secret master key before it's locked up in the safe. This is not that useful by itself, but it becomes potentially very useful if you also include some mechanism to revoke compromised keys, so that e.g. if your daily use key is leaked, you can just revoke it and generate another one.

What I describe above is a rudimentary kind of public key infrastructure. Actually implementing one securely can get quite complicated, but fortunately it's been done before. In fact, whenever you connect to a website (like Wikipedia) using HTTPS, this is pretty much exactly what you browser does: it receives a public key certificate from the server, verifies that the certificate matches the server name in the URL, is not listed as revoked and has been signed by a known and trusted certificate authority, and then uses it to negotiate a temporary symmetric encryption key known only to itself and to the owner of the private key corresponding to the certificate. This symmetric key is then used to encrypt and authenticate all data sent between the client and the server.

In particular, you really should take a look at existing SSL/TLS libraries (which typically come with an X.509 PKI implementation), or possibly at SPKI. These are still somewhat complicated, but probably easier (and more secure) than trying to roll your own.

I'm probably wrong, please correct me if it is so, but I think you're missing the point of the question. He wants to allow people to create their own servers, that report statistics to a master server. When he does that, there is no way that he could actually prevent hacking (@Jari Kompppa has it right). -1 for now. –  jco Nov 30 '12 at 15:01
@Bane: You may be right. I interpreted the phrase "spoofing the master server" in the question as "pretending to be the master server", but after re-reading the question, I can see that he might have meant "sending fake data to the master server" instead. You're right that digital signatures won't help in any way against that. –  Ilmari Karonen Nov 30 '12 at 23:00

This depends on the nature of the game and on the reason you're offloading the server role.

In certain circumstances you might be able to mostly achieve this with cryptographic audit logs. E.g. if it's a two-player turn-based game and you can arrange for each client to have a private asymmetric key for signature purposes, you can have a protocol along the lines of

  • The initial state S0 includes a unique identifier for the game (to prevent replay attacks) and is otherwise assumed to be constant. If there's a random element, that should be produced by the central server and cached there for future comparison.
  • P1 makes move m1; signs the resulting state S1, producing signature C1; and sends it with his move (S1, C1, m1) to P2.
  • P2 makes move m2; signs the resulting state S2, producing signature C2; and sends it with his move (S2, C2, m2) to P1.
  • etc.

At the end both clients submit the result to the central server, and if they disagree then they submit the audit trails: (S1, C1, m1), (S2, C2, m2), etc. Since each player has signed their moves, they are committed to them.

It's still vulnerable to one player DDOSing the other to prevent them submitting their result, but there really isn't much you can do about that.

NB This is just a quick sketch - I'm sure that if you post it to crypto.stackexchange.com someone will poke massive holes in it - but I think the principle is sound. Get whatever scheme you design reviewed by someone who knows their stuff before you start relying on it.

You could avoid the DoS issue by requiring audit logs to be submitted unless all players submit a result and agree on it. However, another issue is that a player who realized they were losing could simply drop out of the game. You could rule that dropping out means losing, but then a player could make it look like their opponent was the one who dropped out by appending an extra move to their audit trail. One way around that would be to allow players to download the submitted audit trails and later amend their own, but that could result in some rather drawn-out games. –  Ilmari Karonen Dec 1 '12 at 22:19

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.