Question

I’m creating an iphone application.

In the application I need to communicate with my database. I’ve looked around and found out that the best way is iPhone -> webserver -> mysql.

And if I use https, the traffic wont be in plaintext.

But I’m still concerned about the security.

Let’s say I’ve got like, auth.php which will auth the current session with the webserver, and if I then have a game or something and register the result with registerresult.php, the users would still be able to login through the auth.php via website and the register their own result in registerresult.php.

(Im using POST method to post the data)

You see the problem?

I’ve looked at this:
http://www.icodeblog.com/2009/10/29/iphone-coding-tutorial-creating-an-online-leaderboard-for-your-games/2/

But, is that really a good way, or is there better? (send a hardcoded “key” with each statement)

If https wasnt used that key would be in plaintext anyway?

Answer 1

(Upgrading to an answer)

It’s impossible to achieve total security: you always have to consider what the threats are (from whom, how resourced they are, etc.) in order to adequately defend against them.

For example, even if you cryptographically sign the result data prior to sending it to your registerresult.php page, the signing key must still be embedded in your app on the user’s phone – therefore a determined cracker could still extract the key and send forged results. I think you’d have to run the game on your server, so that the state information is held there, in order to defeat threats of that nature.

However, it’s unlikely that anyone would go to such lengths to crack an iPhone game (unless perhaps the game was incredibly popular or paid out prizes of some material value). Would it really matter to you if a few highly skilled people succeeded in sending forged results? It’s worth thinking about.

Should you decide that you can tolerate such threats, the approach cited in your question has some flaws. Whilst HTTPS does secure the secret key from being intercepted by a packet sniffer, it does not prevent it being intercepted by a transparent proxy that presents an SSL certificate which is accepted by the phone (such as a self-signed one that has been added to its keychain).

To defeat threats of this sort, I suggest that you calculate a secure hash of (data + random salt value + secretkey) and send (data, that same salt value, that hash) to the server; the server can then recompute what the hash should have been from the known secret key and check that it verifies against the received hash.