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?

  • Comments are not for extended discussion; this conversation has been moved to chat.
    – Rory Alsop
    Oct 12, 2020 at 10:50
  • it is risky to hardcode a shared secret in source code, if the source code is leaked, the important data in the application will also be leaked soon.
    – Ham
    Mar 22, 2023 at 4:17

1 Answer 1


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, 2017 at 18:47
  • I added a comment about handling replay attacks. Good luck :)
    – goteguru
    Aug 7, 2017 at 19:18

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .