Restricting access to server to iPhone app

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 s

Answer 1

Who is your adversary here? Both methods fail to prevent cracked copies of the application from connecting to the server. I think that's the most common problem with iPhone game (or general) development for paid apps.

However, this may protect the server from other non-iPhone clients, as it deters programmers from reverse engineering the network packet interfaces between the iPhone and the server.

Answer 2

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.

Answer 3

No way is perfect--but a challenge/response is better than a key.

A certificate SHOULD use challenge/response. You send a random string, it encrypts it using the certificate's private key, then you get it back and decrypt it with the public key.

Depending on how well supported the stuff is on the iPhone, implementing the thing will be between trivial and challenging.

A nice middle-road I use is xor. It's slightly more secure than a password, trivial to implement and takes at least an hour or two of dedication to hack.

1. Your app ships with a number built in (key).
2. When an app connects to you, you generate a random number (with the same number of bits as the key) and send it to the phone
3. The app gets the number, xor's it with the key and sends the result back.
4. On the server you xor the returned result with the key which should result in your original random number.

This is only slightly hacker resistant, but you can employ other techniques to make it better like changing the key each time you update your software, hiding the random number with some other random number, etc. There are a lot of tricks to hiding this, but eventually hackers will find it. Changing the methodology with each update might help.

Anyway, xor is a hack but it works for cases where sending a password is just a little to hackable.

The difference between xor and public key is that xor is EASILY reversible by just monitoring a successful conversation, public key is (theoretically) not reversible without significant resources and time.