4

I'm writing an iPad game that sends hi-score type data (ie data beyond what Game Center supports) to a Google appengine datastore. It sends these updates via http GET or POST requests, such as http://myapp.appspot.com/game/hiscore/925818

Here is how I thought to ensure the appengine datastore isn't spammed with false data.

zip/encrypt the payload data using hardcoded p@ssw0rd saved in the iOS binary. Encode that binary data as base64. Pass base64 payload in the url query string or in the POST data. At handler, unbase64, then unzip data with p@ssw0rd. Follow instructions in payload to update highscore-type data.

CON: If p@ssw0rd is somehow derived from the iOS binary, this scheme can be defeated.

Is this adequate/sufficient? Is there another way to do this?

bobobobo
  • 64,917
  • 62
  • 258
  • 363
  • This is similar to http://stackoverflow.com/questions/8670612/what-are-the-best-practices-for-making-online-high-score-lists-in-javascript-bas – mfanto Dec 19 '12 at 21:01
  • To complete this I need [SecKeyEncrypt](http://developer.apple.com/library/ios/#DOCUMENTATION/Security/Reference/certifkeytrustservices/Reference/reference.html#//apple_ref/doc/uid/TP30000157-CH1g-SW26), and to use SSL. – bobobobo Apr 07 '13 at 06:42

2 Answers2

3

There is absolutely no way to make sure it's your client that sends the data. All you can try is to obfuscate some thing to make it harder for spammers to submit data.

However I think there are two thing you can do:

  1. Have some kind of secrect key saved in the binary
  2. Have a custom algorithm calculating some checksum

Maybe you can go with a combination of both. Let me give you an example:

Create some custom (complex!) alorithm like (simplyfied):

var result = ((score XOR score / 5) XOR score * 8) BITSHIFT_BY 3

Then use your static stored key with that result and a well known hash function like:

var hash = SHA256(StaticKey + result)

Then send that hash with the score to the server. The server has to "validate" the hash by performing the exact same steps (evaluate algorithm + do the SHA256 stuff) and compare the hashes. If they match the score hopefully comes from your app otherwise throw it away, it comes from a spammer.

However this is only one thing you can do. Have a look at the link from mfanto, there are many other ideas that you can look at. Be sure to not tell anybody about how you're doing it since this is security through obscurity.

Community
  • 1
  • 1
GameScripting
  • 16,092
  • 13
  • 59
  • 98
  • 1
    Second that. The more different paths you employ which lead to the secret key, the longer it will last. Use random strings that don't seem to make sense when seen amidst the binary. Split the string and define different parts in different places. Don't combine them all at one. Salt'em. Hash'em. Be creative :) – Toastor Jan 20 '13 at 21:01
  • 1
    @bobobobo what makes you think banks can do it? What's to stop a spammer from, say, running your code in a debugger on a jailbroken device and modifying the score variable before the client encodes & transmits it? – Jesse Rusak Apr 21 '13 at 16:52
  • __Yes__ they _can_ do this, but the point of security is _to make it harder_ for clients to cheat. You could embed final gamestate or replay data and set up some type of validation mechanism for suspicious scores. – bobobobo Apr 21 '13 at 17:21
0

Ok me, there are 2 methods to do this.

1) Purchase an SSL certificate for $FREE.99 and open HTTPS connections only to your server to submit hiscore type data. Connection speed should be around 500 ms due to handshake roundtrip time.

2) Embed an RSA public key certificate in your iOS app, and have the RSA private key on your server.

You can then do 1 of 2 things with this second scheme:

  • IF your data messages are really small (≤256 B) you can just encrypt and send 256B packages (RSA payload is limited by the number of bits in the key)

  • ELSE IF the data is too large (>256B), generate a random symmetric key (AES), and pack:

    • SYMMETRIC AES KEY ENCRYPTED WITH RSA PUBLIC KEY
    • BINARY DATA ENCODED WITH SYMMETRIC AES KEY

The server then takes the first 256 bytes and decodes it, then the server uses that AES key to decrypt the rest of the message.

The above 2 only prevent eavesdropping, but it means the data format of your messages is hidden. At some level, it is still a type of security by obscurity, since if the hacker has your public key AND your message format, they can manufacture messages.

Community
  • 1
  • 1
bobobobo
  • 64,917
  • 62
  • 258
  • 363