0

I'm building an iPhone app that needs to communicate with a PHP api. It will send its data via POST. Not that I have any sensitive data concerns, but I am curious as to how I can ensure that the POST is coming from: the app; or the device; or at least an iPhone.

Jake Wharton's answer on this answer talks about a "known call and response pattern" and I will use that method if there is know other way: How to ensure/determine that a post is coming from an specific application running on an iPhone/iTouch?

I'm not needing SSL or anything, but I will implement low-tech protective measures where possible.

Community
  • 1
  • 1
Warren
  • 1,984
  • 3
  • 29
  • 60
  • How concerned are you that the POST may be coming from an impostor, iOS app, Android app or a computer? – zaph May 19 '14 at 00:32
  • I'm not really worried as I can validate database entries and I can limit the records per user etc, but I am more curious about how to mitigate the risk of some wizkid sniffing the post data and then posting to the api for fun at my cost. – Warren May 19 '14 at 00:49
  • The question is **how** concerned. Express that "cost" in Dollars, Euros, Swiss Franks, etc.. Then you can determine him much security you need. – zaph May 19 '14 at 00:53

1 Answers1

0

You could use a token string that you send with each request that only your app would know and verify it on the server, but you should probably use SSH so no one can sniff your token.

edit:

So my first answer was a little flawed. Another thing you could try is creating a signature by encoding the data you are about to send with some secret key using HMAC and send the signature in the header with your request. Then on the server sign the data again using your secret key and make sure they match. I think this should still be combined with SSL, but I think it can give you a reasonable assurance that the data is coming from your app. Without SSL it would be possible for someone to do replay attacks.

BradiaLabs
  • 41
  • 3
  • But an attacker can sniff the token. – zaph May 19 '14 at 00:54
  • That's why I said he should use SSH for that solution – BradiaLabs May 19 '14 at 00:55
  • The OP stated "I'm not needing SSL". But even with SSL there is a really good chance I can still sniff it. An example: I can sniff the SSL going to the Apple developer servers and get the password. – zaph May 19 '14 at 00:57
  • I guess I wasn't aware you could crack SSL so easily. – BradiaLabs May 19 '14 at 01:02
  • It is not cracking SSL, if you have the device it is just using a proxy such as Charles Proxy. You are protected on the net. There are ways to make it harder but one can still get around most. – zaph May 19 '14 at 01:05
  • I see, I didn't think of that. How about using the token to encrypt the data so only the server would know how to decrypt it? – BradiaLabs May 19 '14 at 01:07
  • There are many good authentication schemes, it is best to use one that has been throughly vetted. Rolling one's own scheme is almost guaranteed to have serious flaws. But the first question is the dollar cost of an attack and to protect to that level. If you want to see high-end crypto just read Apple's explanation of how iMessage keys are held at Apple. Hint: Even Apple can not access them. – zaph May 19 '14 at 01:10
  • I definitely agree with that – BradiaLabs May 19 '14 at 01:12