1

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?

netdigger
  • 3,659
  • 3
  • 26
  • 49
  • Even if you cryptographically sign the result data prior to sending it to `registerresult.php` (which would make it a lot harder for people to forge), the signing key must still be embedded in your app on their phone... therefore a determined cracker could still forge results. I *think* you'd have to run the game on your server, so that the state information is held there, in order to be certain that users cannot submit forged results (but I'm very interested to hear alternatives from others!). – eggyal Apr 29 '12 at 12:43
  • Yeah, thats what I mean, to store the key locally doesn't seem very optimal. Although at the moment that's probably what I'll do, I mean how much effort will people put into submitting fakescores :) (hope I wont have to eat that up :P) – netdigger Apr 29 '12 at 12:49
  • 1
    I suppose the amount of effort people might put in will be some function of how successful/important your game is, or what prizes can be won. If you go down this route, the approach in the article you cite is not very good (a mere packet sniffer would see the secret key) - it would be better to take a secure hash of (data, random salt value, secretkey) and send (data, that same salt value, hash) to the server which can recompute the hash from the known secret key and check that it verifies. – eggyal Apr 29 '12 at 12:53
  • Yeah, that's a better idea! But a package-sniffer wont see that key I'm communicating with https, or? – netdigger Apr 29 '12 at 12:58
  • Actually, I'd overlooked that it was using HTTPS - in which case the secret key would *not* be intercepted by a packet sniffer. However, a transparent proxy using a self-signed cert that has been added to the phone's keychain *would* enable a cracker to intercept the secret key, so I'd still recommend my approach. – eggyal Apr 29 '12 at 13:02

2 Answers2

2

(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.

eggyal
  • 122,705
  • 18
  • 212
  • 237
  • +1 I would add the additional layer on top of HTTPS and make them dig for the key in the application. Don't rely just on HTTPS, as eggyval stated. Also, one more thing to consider...record the moves in the game and send it to the server. The server could replay it to see if it arrived at the same score. – Marcus Adams Apr 29 '12 at 13:59
0

the above user @eggyal is said is the best answer. U better to use cryptography in ur project then after that u wil send data to ur server file for database. On the server side, you wil decrypt ur received data from front end, then after that u wil communicate with data base. it wil be the secure communication. Use encrypt and decrypt method.

Here is the link for Encryption and decryption.

Community
  • 1
  • 1
Ravi Kumar Karunanithi
  • 2,151
  • 2
  • 19
  • 41