I am building a Web API for a simple game. The API is SSL-only and uses limited-time tokens for user authentication. I would like to encrypt the contents of a specific request to prevent cheating.

I understand that to do that I will need to make available some encryption keys to the client application (to which the user has full access), so the solution will not be 100% secure against reverse engineering.

Still, I feel that something is better than nothing and am wondering what the best approach would be.

I have come up with a couple of alternatives:

  1. Hardcode a shared secret in the application source code.
  2. Use the user's current session token in combination with some obfuscation algorithm and use the result as the encryption key.

I don't particularly like either of these so I wanted to check if there is a better way. Any ideas?

  • Can you clarify your goal? How can the user cheat without your planned method? What exact activity would you like to prevent? – goteguru Aug 2 '17 at 20:55
  • I am getting GPS coordinates, detected by the user's phone. The user being at a particular location at a particular time is part of the game mechanics. I want to prevent the user from just typing in coordinates and sending them to the API. – Shade Aug 3 '17 at 11:08
  • 1
    @Shade you are now in the same problematic field the Niantic Labs are with Ingress and Pokémon Go. And even they can't do that perfect. A user have many ways to tell your API the GPS Coordinates. From just send a modified Message they previously send to Change the GPS Coordiantes with a rooted/emulates devices on OS Level (you App can't know this without getting root access too, which the user can deny and you don't know if they just deny the root access or they are cheating ) – Serverfrog Aug 7 '17 at 13:29
  • @Serverfrog The mere fact that some random Corp can't do it right won't neccessarily mean you can't do it right. Many-many proprietary code is extremely low quality and poorly designed. Some are not. The fact, they can not prevent a simple replay attack, suggests that they fell into the first category. There are also methods to detect rooted devices and exclude them from the game. Of course it's an arms race. There is no way to win this war, but there is a way not to loose badly. – goteguru Aug 17 '17 at 13:59
  • @goteguru Niantic == internal Google Startup != random Corp – Serverfrog Aug 17 '17 at 16:08

As you correctly stated, if the user has control over her device, it is not possible to stop cheating. She can monitor the GPS input, reverse-engine the code, identify encryption (if any) and send the request accordingly.

Obfuscation is questionable, it may slow down (but wont stop) the attacker. You will hurt your own debugging capabilities and clean design.

The proper design is the following: send the request in clear text for your API, but sign it. Your API should reject all requests which is signed incorrectly. Just add one more parameter field to your api, which contains the signature.

You can use your own PKI or simple hash generation (if performance is an issue). Of course, the attacker can still reverse-engine the signature algo, but let's suppose she hasn't got the skill.

Edit: I suggest you to include timestamp to the API to prevent replay attack. (Of course the timestamp should be digitally signed along with the rest of the data). This way your users can not save location URL strings and manually replay it when they are not at that area. Without timestamps they could do that regardless of the use of encryption.

  • 1
    Thanks for the answer. I guess we'll have to get creative. – Shade Aug 7 '17 at 18:47
  • I added a comment about handling replay attacks. Good luck :) – goteguru Aug 7 '17 at 19:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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