We are creating a turn based multiplayer game in Unity where client data is sent to the server (SSL encrypted) using JSON to update player currency, gear, etc. We have hit a road block with client verification. We need to be able to verify the Client application is indeed the Client.

For example - to update player gold to 100, the client would send the following URL Request:

example.com/update.php?player_id=1&gold=100&session_id=1234asdf

What is to keep someone from calling that exact same address in a browser and changing 100 gold to 10000000?

Option 1:

Create session_id based on algorythm stored in client code to verify?

FAIL

When creating a mobile game in Unity for Android, users can easily download the APK and view the source and see the algorythm.

Option 2:

Create session_id on server and send to client for later use?

FAIL

A network packet sniffer can intercept session_id being sent back down to the client.

In both cases, the above URL can be modified with a spoofed session_id and player gold set to 10000000 instead of 100.

Are we stuck with TCP ports for all client / server communication or can we still use JSON? If so, how can we use it securely?

Thank you!!!

What is to keep someone from disassembling your client and sending the same 1mil gold request from Client itself?

Number One Rule:

never trust a client

The solution to your problem is to change protocol from:

Client: "I opened this chest and now I have 100 more gold"

Server: "Ok"

to something like:

Client: "I want to open this chest".

Server: "You succeeded. This chest contained a treasure. You now have 100 more gold".

Client: "Ok"

Thanks for your reponse! It is very helpufl.

To follow up, how do we trust the client when it asks to open the chest?

For example, in our game there are battles where the player battles the computer and then reports to the server success or failure. We can modify the reward logic (as you suggested) to all be server side; however, we still have to 'trust' the client's battle success or failure response. Any ideas?

Thanks again!

We need to be able to verify the Client application is indeed the Client.

You cannot. The game world is littered with corpses of games that thought you could do that. This forum is littered with threads from otherwise smart engineers who thought they could do that.

how do we trust the client when it asks to open the chest?

You either run a simulation on the server side, that makes it possible to verify that the player is, in fact, close to the chest, OR you design the game play such that it doesn't really matter whether the player is close to the chest or not -- perhaps chests are only generated once the player completes some other checkpoint, and you assume that it's supposed to be openable after that.

the player battles the computer and then reports to the server success or failure

If you want this to be cheat proof, then you need to run a simulation on the server that verifies that the player did in fact get the result.

The other alternative is to focus more on the game being fun, and don't worry about the cheaters. This works for single-player experiences; not so much for multiplayer.

example.com/update.php?player_id=1&gold=100&session_id=1234asdf

If, and only if, the URL is generated by the server and then sent to the client, then you could use a hash to confirm that the URL hasn't been tampered with:

$url = 'http://example.com/update.php?player_id=1&gold=100&session_id=1234asdf';
$url .= '&hash='.secret_hash($url);
print $url;

http://example.com/update.php?player_id=1&gold=100&session_id=1234asdf&hash=0123456789ABCDEF

If a malicious player were to change the gold, then the hash wouldn't match on the server and the request would be denied.
Again, as hplus has suggested, it would be better if the URL described an action a player is doing, rather than "raw game code".