Question

I’m building a client/server iPhone game, where I would like to keep third-party clients from accessing the server. This is for two reasons: first, my revenue model is to sell the client and give away the service, and second I want to avoid the proliferation of clients that facilitate cheating.

I’m writing the first version of the server in rails, but I’m considering moving to erlang at some point.

I’m considering two approaches:

1. Generate a “username” (say, a GUID) and hash it (SHA256 or MD5) with a secret shipped with the app, and use the result as the “password”. When the client connects with the server, both are sent via HTTP Basic Auth over https. The server hashes the username with the same secret and makes sure that they match.

2. Ship a client certificate with the iPhone app. The server is configured to require the client certificate to be present.

The first approach has the advantage of being simple, low overhead, and it may be easier to obfuscate the secret in the app.

The second approach is well tested and proven, but might be higher overhead. However, my knowledge of client certificates is at the “read about it in the Delta Airlines in-flight magazine” level. How much bandwidth and processing overhead would this incur? The actual data transferred per request is on the order of a kilobyte.

Answer 1

Have your game users authenticate with their account through OAuth, to authorize them to make game state changes on your server.

If you can’t manage to authenticate users, you’d need to authenticate your game application instance somehow. Having authentication credentials embedded in the binary would be a bad idea as application piracy is prevalent and would render your method highly insecure. My SO question on how to limit Apple iPhone application piracy might be of use to you in other ways.