Forum ‹ BigDB ‹ Securing traffic between BigDB and client

[moserm]

This is almost certainly a stupid question, because I've only just started looking at PlayerIO. I am working on a single-player mobile game in AIR. The game has a number of purchasable items and we want to take reasonable measures to discourage cheating.

We want to serve game configuration info from BigDB, so we need to make sure that players can't just rewrite the server response, e.g. to give themselves infinite health (it's a shooter). I can see enough intelligible information in the traffic between my AS3 client and BigDB that I can tell it's not encrypted.

If I want to encrypt the traffic to discourage players from rewriting responses, my understanding is that I need to set up a wrapper on a server somewhere that encrypts and decrypts client traffic based on a shared key and then reads and writes to/from the DB on the client's behalf.

Okay so far. The probably-stupid question is, do I have to set up an external server just to do this (in which case I wonder why I don't just set up my own database and skip PlayerIO)? Or is there a way I can build it into the server-side dll?

[Henrik]

Well, that's not a very effective way of doing it. To do the encryption you must put the key and algorithm in the client, which means a hacker has access to those as well and can make a fake client that writes whatever to BigDB, and then your entire encryption scheme might as well not be there in the first place.

The proper way to do it is to not allow BigDB writes from the client at all. Only do writes through serverside code. This allows you to do sanity checks of the requests you get from the client, and you can do all the purchase handling serverside as well. You can also do some sort of scrambling of the messages you send if you really want to, but remember that it's ultimately useless.

[moserm]

You're right that writing directly from the client is a bad idea. But what I'm asking about is related to getting game information *from* BigDB, not writing to it. We want to store config information on the server side and request it at the beginning of each game, and we don't want players to be able to rewrite the server responses easily. The same concern applies even if we do all the writes server-side; if I'm ultimately relying on the server to tell me how many health packs the player has purchased, that information has to come down the wire in some form and I don't want it to be trivial to rewrite healthPacks=1 to healthPacks=100.

For what it's worth, the client here isn't a web game; it's an encrypted and obfuscated swf (probably using Kindi) packaged inside an ipa or apk living on a mobile device. Nothing is hack-proof, but we're just trying to keep things out of reach for most people most of the time.

So, after doing a bit more research (again, just getting started here) it looks like I'm not limited to calling the functions that are built into the PlayerIO libraries in the server-side code. I can define my own functions which do whatever I want (including encrypt/decrypt) and I can call those functions from the client. Right?

[Henrik]

http://playerio.com/documentation/multiplayer/messages

Between the multiplayer client and server you send custom messages that can contain whatever, so for example you could have the client send a message meaning "how many healthpacks do I have?", and the server responds with a message with the amount, and then you encode/encrypt/obfuscate that information in those messages in some way.

It's perfectly ok to use the multiplayer service even though you're not doing a multiplayer game, just make your serverside code ignore the userjoin and userleave events, put everyone in service-rooms, ignore sending and broadcasting to other players, and just make some simple code that responds to messages from the client in the GotMessage method.