Secure Communication Between iPhone and Server?

Question

I'm developing an app which connects to an XML based API. I have control over both the server and the app - is there any way I can make sure only my app can access the API?

There is no user authentication.

EDIT:

The main concern is that bots steal data by scanning the XML.

How about this:

I request a session with the device UDID and I get a handshake key.

<handshake>23354</handshake>

from this string a password is calculated on both the server and the client according to an agreed algorithm (it just has to be hard to reconstruct)

Let's say for now that I add 1 to the handshake key

password = 23354

On all API calls I then pass this password along with the UDID. This would allow the server to limit each session to a certain number of calls, no?

What do you think?

Answer 1

No, it is not possible to really ensure that only your app can contact your server. There are obfuscation techniques for raising the bar somewhat on attackers, and those will work for most attackers. Your underlying problem is not solvable for a dedicated attacker. You can find a list of other posts on this subject at iPhone: How to encrypt a string . There are several techniques you can use in those posts, and some discussion of how and whether you should attack the underlying issues.

Answer 2

You can provide a quick challenge response mechanism, assuming you have control over the XML api.

Generate a number and include it in your app and on the server side. Use that as a seed to srand() on both client and server.

Have the request from the client include something like:

<handshake id="123">12312931</handshake>

there id means the 123'rd generated random number and 12312931 is the value after calling rand() 123 times. The value 123 should be a randomly generated number (generated with a different seed!) as well.

This isn't a fool proof challenge response, but it's simple and efficient, and doesn't rely on anything more than a basic ANSI C library set.

Note that it's not terribly secure, either - all one would have to do is have your client challenge their own server, then generate the (in this example) 123'rd random number for every seed value until they find it. So I wouldn't use this expecting it to provide cryptographic level authentication or access control. It just provides a simple non-trivial challenge response that is efficient and simple to implement.

Answer 3

You can use some sort of signature in order to verify that it is indeed your app making the call, you calculate the signature both server side and app side, only if they match will the service return with a response to the request. Typically signatures are composed of some s ort of parameters of your function followed by a secret key, then take the md5 hash of that and sned it through. In the r equest no one will be able to find the secret key because it is in the md5 hash.

Answer 4

通过https访问您的Web服务并进行身份验证。

Answer 5

I think the real question you need to ask is how much is your data at risk of attack. I'd say 99% of the time you'll be fine with just an obfuscated URL that will be hard to guess, since chances of the average user trying to do anything with it outside your app are slim. If you're worried about competitors stealing from you, I'd suggest something a little more nefarious:

In your app, set it up so that your app and server change URLs every so often, maybe every two weeks. Then if someone does attempt to access your XML API, they'll be fighting a constant battle of figuring out your URLs. And as icing on the cake, keep the old URLs active but have them return bad data. I think you can let your imagination run and figure out the rest from here.