I have an iPhone app that communicates with a server (both of which I own and wrote the code for). I need to way to determine if a request on my server came from an iPhone (or any mobile device running the app I wrote for that matter). Basically, I only want to allow apps that I wrote to communicate with the server and need a way to verify that. Since I'm writing the apps, I can modify the headers and what not any way I need to.
I read up a little on Public Key Encryption, but I don't think it'd work. If I sent some sort of secret hashed word in my headers to verify it, couldn't some outside party simply get those headers and use the same ones in their request?
You can use a checksum. Let's say that you have something like:
date
subject
and calculate the checksum by using, let's say MD5 of (date + "string" + subject),
and you calculate the MD5 in the very same way on the server. If they match, they are from the mobile client.
This will work until someone figures out your algorithm.
You could have your server send a message to your app that contains a random code. This message and code changes every time it is sent.
Your app then does some kind of algorithm on that message to "encrypt" it and send it back to the server and the server can then check it. That way there's nothing to intercept and use without knowing your "encryption".
Of course, they could intercept the message from each direction and then work out your algorithm, but if you make it sufficiently difficult, then that would be a while.
You could just use HTTP Basic authentication, unless you needed something more secure.
Related
I'm trying to send data from my application to a webserver.
The catch is that I want to encrypt the sent data and also make sure it comes from my application. (From what I've read so far it's easy to decrypt the data if it's not sent via HTTPS. On the unique application I didn't find anything except the Application ID Apple provides for each application but I don't know how that works).
The data sent are various highscores and achievements that the user can enable. The thing is that the user doesn't have to type in anything but his username and having that associated with the UDID it should be enough.
But how to make sure it's from my application?
Edit:After reading some responses around here I still didn't understand something:
If someone extracts the IPA and reverse engineers it wouldn't he have access to all my .h and .m so he can look up anything in there?
You could generate a client certificate for the iPhone app, and use mutual authentication for your SSL handshake. Then you know that data submitted to the server come from a particular user of the app, and that your app is communicating with the correct server.
Regarding your edited update, yes if someone reverse-engineeres your app they can probably work out how the high-scores are protected. But seriously, how much trouble do you expect most people to go to in order to fake a high score in a game? Are you offering a cash prize or something?
If you are using HTTPS then you can just put an identifier key in your POST to the web server, either as a field or perhaps an HTTP header that identifies your app. The entire connection is encrypted so it will be protected. If you do this you will want to encrypt the key even in your binary and decrypt it as you send it over the connection, that way no one will be able to pull it out with a hex editor.
Another approach if all you want is to know that the data comes from an authentic instance of your application is to use message authentication codes (MAC). I leave deciding how strongly the key needs protecting as an exercise to the reader - you know your security requirements better than I do.
You can use CommonCrypto - part of the iOS SDK since forever - to actually generate the MAC.
I don't mind so much about pirating etcetera, but I want to ensure that the backend (Rails based) isn't open to automated services that could DOS it etc. Therefore I'd like to simply ensure that all access to the backend (which will be a few REST queries to GET and PUT data) will be via a valid iPhone application, and not some script running on a machine.
I want to avoid the use of accounts so that the user experience is seamless.
My first intention is to hash the UDID and a secret together, and provide that (and the UDID) over a HTTPS connection to the server. This will either allow an authenticated session to be created or return an error.
If eavesdropped, then an attacker could take the hash and replay it, leaving this scheme open to replay attacks. However shouldn't the HTTPS connection protect me against eavesdropping?
Thanks!
Like bpapa says, it can be spoofed, but then, like you say, you aren't worried about that so much as anybody coming along and just sending a thousand requests to your server in a row, and your server having to process each one.
Your idea of the hash is a good start. From there, you could also append the current timestamp to the pre-hashed value, and send that along as well. If the given timestamp is more than 1 day different from the server's current time, disallow access. This stops replay attacks for more than a day later anyway.
Another option would be to use a nonce. Anybody can request a nonce from your server, but then the device has to append that to the pre-hash data before sending the hash to the server. Generated nonces would have to be stored, or, could simply be the server's current timestamp. The device then has to append the server's timestamp instead of its own timestamp to the pre-hashed data, allowing for a much shorter period than a full day for a replay attack to occur.
Use SSL with client certificate. Have a private key in your client and issue a certificate for it, and your web server can require this client cert to be present in order for the sessions to proceed.
I can't give code details for Rails, but architecture-wise it's the most secure thing to do, even though might be a bit overkill. SSL with certificates is a standard industry solution and libraries exist for both the iPhone/client end and server end, so you don't have to invent anything or implement much, just get them to work nicely together.
You could also consider HMAC, like HMAC-SHA1, which is basically a standardization of the hashes stuff that other people here talk about. If you added nonces to it, you'd also be safe against replay attack. For an idea about how to implement HMAC-SHA1 with nonces, you could look at OAuth protocol (not the whole flow, but just how they tie nonce and other parameters together into an authenticated request).
There is no way to ensure it, since it can be spoofed.
If you really want to go this route (honestly, unless you're doing something really super mission critical here you are probably wasting your time), you could pass along the iPhone device token. Or maybe hash it and then pass it along. Of course, you have no way to validate it on the Server Side or anything, but if a bad guy really wants to take you down, here is roadblock #1 that he will have to deal with first.
I am developing an iPhone app together with web services. The iPhone app will use GET or POST to retrieve data from the web services such as http://www.myserver.com/api/top10songs.json to get data for top ten songs for example.
There is no user account and password for the iPhone app. What is the best practice to ensure that only my iPhone app have access to the web API http://www.myserver.com/api/top10songs.json? iPhone SDK's UIDevice uniqueueIdentifier is not sufficient as anyone can fake the device id as parameter making the API call using wget, curl or web browsers.
The web services API will not be published. The data of the web services is not secret and private, I just want to prevent abuse as there are also API to write some data to the server such as usage log.
What you can do is get a secret key that only you know, Include that in an md5 hashed signature, typically you can structure signatures as a s tring of your parameters a nd values and the secret appended at the end, then take the md5 hash of that...Do this both in your client and service side and match the signature string, only if the signatures match do you get granted access...Since t he secret is only present i n the signature it w ill be hard to reverse engineer and crack..
Here's an expansion on Daniel's suggestion.
Have some shared secret that the server and client know. Say some long random string.
Then, when the client connects, have the client generate another random string, append that to the end of the shared string, then calculate the MD5 hash.
Send both the randomly generated string and the hash as parameters in the request. The server knows the secret string, so it can generate a hash of its own and make sure it matches the one it received from the client.
It's not completely secure, as someone could decompile your app to determine the secret string, but it's probably the best you'll get without a lot of extra work.
Use some form of digital signatures in your request. While it's rather hard to make this completely tamper proof (as is anything with regard to security). It's not that hard to get it 'good enough' to prevent most abuse.
Of course this highly depends on the sensitivity of the data, if your data transactions involve million dollar transactions, you'll want it a lot more secure than some simple usage statistic logging (if it's hard enough to tamper and it will gain little to no gain to the attacker except piss you of, it's safe to assume people won't bother...)
I asked an Apple security engineer about this at WWDC and he said that there is no unassailable way to accomplish this. The best you can do is to make it not worth the effort involved.
I also asked him about possibly using push notifications as a means of doing this and he thought it was a very good idea. The basic idea is that the first access would trigger a push notification in your server that would be sent to the user's iPhone. Since your application is open, it would call into the application:didReceiveRemoteNotification: method and deliver a payload of your own choosing. If you make that payload a nonce, then your application can send the nonce on the next request and you've completed the circle.
You can store the UDID after that and discard any requests bearing unverified UDIDs. As far as brute-force guessing of necessary parameters, you should be implementing a rate-limiting algorithm no matter what.
A very cheap way to do this could be getting the iPhone software to send extra data with the query, such as a long password string so that someone can't access the feed.
Someone could reverse engineer what you have done or listen to data sent over the network to discover the password and if bandwidth limitations are the reason for doing this, then a simple password should be good enough.
Of course this method has it's problems and certificate based authentication will actually be secure, although it will be harder to code.
The most secure solution is probably a digital signature on the request. You can keep a secret key inside the iPhone app, and use it to sign the requests, which you can then verify on the server side. This avoids sending the key/password to the server, which would allow someone to capture it with a network sniffer.
A simple solution might be just to use HTTPS - keeping the contents of your messages secure despite the presence of potential eavesdroppers is the whole point of HTTPS. I'm not sure if you can do self-signed certificates with the standard NSURLConnection stuff, but if you have a server-side certificate, you're at least protected from eavesdropping. And it's a lot less code for you to write (actually, none).
I suppose if you use HTTPS as your only security, then you're potentially open to someone guessing the URL. If that's a concern, adding just about any kind of parameter validation to the web service will take care of that.
The problem with most if not all solutions here is that they are rather prone to breaking once you add proxies in the mix. If a proxy connects to your webservice, is that OK? After all, it is probably doing so on behalf of an iPhone somewhere - perhaps in China? And if it's OK for a proxy to impersonate an iPhone, then how do you determine which impersonations are OK?
Have some kind of key that changes every 5 minutes based on an algorithm which uses the current time (GMT). Always allow the last two keys in. This isn't perfect, of course, but it keeps the target moving, and you can combine it with other strategies and tactics.
I assume you just want to dissuade use of your service. Obviously you haven't set up your app to be secure.
I am writing a very simple web service for my iPhone app. Let's say this is a http page that returns a random number at http://mysite/getRand. How do I ensure that this page can only be accessed from my iPhone app and not from other clients? I've thought of doing some simple password mechanism but that can easily be sniffed by capturing what my app sends out.
The reason for this is to lower the load of my server by only allowing legitimate requests.
You can't really do this. Your application can be disassembled and whatever secret is in the binary can be replicated in a malicious application.
Another attack you should be aware of is people settings the hosts file to a location they control and then installing a root certificate that allows them to provide a signature for that domain. Your application would do the post with the secret, and they'd just be able to read out the secret. They could extract the password from any complicated encryption system within the binary in this way.
Most of the ideas in this thread are vulnerable to this attack.
That said, the likelihood of somebody caring enough to disassemble your application is probably fairly remote.
I'd just keep it simple. Have a password that's hardcoded in to your application. To prevent someone just looking at the resources and trying every string, make it the XOR of two strings or the result of an AES decrypt of a particular fixed string.
Obviously, you should do the request over SSL otherwise an attacker can just sniff the traffic.
Yes, a determined attacker will circumvent the scheme but like any DRM scheme, that's always been the case. The trick is to make it too much effort to be worth it.
To follow up on Simon's idea, you could very easily have a key string in your application, then send the device ID, and then the DeviceID XOR'ed (or some other simple algorithm for string encryption) with your key string.
Since you know the key value to use, it's trivial for you to "decrypt" this string on the sever side and verify that the values match.
This way, the password is different for each user's device, and the "key" string is never sent over the wires of the great unwashed internets. :-)
Yes, this would by no means be impossible to figure out, but like others have said, the idea is not to make it impossible. The idea is to make it more trouble than it is worth.
I would use the https protocol with client-side keys too. You can use one client key for everyone or you can even generate a different key for each client and "register" them at your server.
I suppose that it's a lot of work for small project, but it sounds like the appropriate thing to do if you need authentication.
You should check that keys aren't seen easily by mobile phone owner. And remember that somebody will be able to hack it in any case.
Here's one thought - send up the device ID along with requests from your app.
Monitor the device ID's used - if you see a ton of requests from different IP's near or at the same time, that device is probably being used as a fixed key in the requests sent to you - block it.
For those that actually send the real device ID from other apps (not yours), you can monitor usage trends to see if the calls match the pattern of how your app performs - like one call being used by a device before some initialization call you would normally expect, and so on - block those too.
Basically by being able to shift rules around patterns of use, you can better adjust to someone trying to use your service by making sure it's not a fixed target like some random use key would be.
You may also want to use a simple use key as well as a first line of defense, and then layer on the traffic analysis approach. Also custom http header values you look for are another simple way to trip up a naive attacker.
I am assuming you don't want to use SSL? If you do then you can open HTTPS session and then pass some secret key in the request.
If you don't want SSL your options are limited: to have pseudo security I suggest both authentication and authorization methods and a third to reduce overall traffic:
Authentication: Generator in client application that creates secret keys by combining with a key file. The keyfile can be updated every so often for greater security: lets say you update the key file once a week. To re-cap: Generator combines in app secret with out of app key file to generate a 3rd key for transmission used in authentication. The server would then be able to authenticate.
Authorization: Of course you also want to lock out rogue applications. Here it would be best to have authorization mechanism with the site. Don't replace keyfiles for unless the client logs in. Track key files to users. etc.
Traffic reduction:
If you are receiving obscene amount of traffic or if you suspect someone trying to DOS your server, you can also have both the server and clients sync to request/response on a procedurally generated URL that can change often. It is wasteful to open/close so many HTTPS sessions if someone is just flooding you with requests.
I'm not sure what web technology you are using, but if you are using Ruby on Rails, it uses a secret authentication token in all of its controllers to make sure malicious code isn't accessing destructive methods (via PUSH, POST, or DELETE). You would need to send that authentication token to the server in your request body to allow it to execute. That should achieve what I think you are looking for.
If you're not using Ruby on Rails, that method of code authentication might be a good one to research and implement yourself in whatever technology you are using.
Take a look at the Rails Security Guide, specifically section 3.1 (CSRF Countermeasures).
You could do something like encrypting the current time and IP address from the iPhone, and then decrypt it on the server. The downside is that you need the iPhone app to know the "secret" key so that only it can generate valid access tokens... and once the key is in the wild, it will only be a matter of time before it's hacked if your app is really worth the effort.
You could encrypt the response using some random portion of the application which is meant to be using it, specifying the location of the binary in an unencrypted bit of the response. Then at least only clients with access to your binary would be able to decrypt it... but again, that's hardly 100% secure.
Ultimately you need to ask yourself how much effort you want to put into securing the service vs how much effort you think hackers will put into abusing it.
I'm not an Cocoa Touch developer, but I think HTTP Authentication over SSL would be easy to implement and it's probably exactly what you're looking for.
All you need to do is setup HTTP Authentication on the server side (you haven't mentioned what you're using on the server side) and create a self-signed SSL cert on your webserver. Done. :)
Tell us more about your setup and we will be able to help you further.
As some of the answers have stated, closing your web service off to everyone else will be a major hassle. The best you can hope for is to make it easier for the hackers to use another web service, than to use yours...
Another suggestion to do this, is to generate random numbers from a random seed on both the server and the client. The server would need to track where in the sequence of random numbers all of the clients are, and match that number to the one sent by the client.
The client would also have to register to be given access to the server. This would also serve as a authentication mechanism.
So:
//Client code:
$sequence = file_get_contents('sequence.txt');
$seed = file_get_contents('seed.txt');
$sequence++;
//Generate the $sequence-th random number
srand($seed);
for ($i = 0; $i <= $sequence; $i++) {
$num = rand();
}
//custom fetch function
get_info($main_url . '?num=' . $num . '&id' = $my_id);
This will generate a request similiar to this:
http://webservice.com/get_info.php?num=3489347&id=3
//Server Code: (I'm used to PHP)
//Get the ID and the random number
$id = (int)$_REQUEST['id'];
$rand = (int)$_REQUEST['num'];
$stmt = $db->prepare('SELECT `sequence`, `seed` FROM `client_list` WHERE `id` = :id');
if ($stmt->execute(array(':id' => $id)) {
list($sequence, $seed) = $stmt->fetch(PDO::FETCH_ASSOC);
}
$sequence++;
//Generate the $sequence-th random number
srand($seed);
for ($i = 0; $i <= $sequence; $i++) {
$num = rand();
}
if ($num == $rand) {
//Allow Access
} else {
//Deny Access
}
By using a a different seed for each client, you ensure that hackers can't predict a random number by tracking previous numbers used.
I'm working on a game for the iPhone and would like it to be able to submit scores back to the server. Simple enough, but I want the scores to be verified to actually come from a game-play. With the (defacto) prohibition on real crypto with the export conditions, what would be the best way to get information back in a secure/verified channel?
All my thoughts lead back to an RSA-style digital signature algorithm, but would prefer something less "crypto" to get past that export question.
Thanks!
Couldn't you just use a client certificate (signed by you) and establish an HTTPS connection to your server, which has been configured to only accept connections begun with a client certificate signed by you?
To make a long story very short, you're allowed to export digital signature code with very few restrictions. To learn more, start at the BIS export FAQ.
You probably want to look at EAR 742.15(b)3, which covers the digital signature exemptions.
Of course, I Am Not A Lawyer, and the rules may have changed in the last year.
Using real crypto won't actually buy you anything here. You basically have the reverse of the typical DRM problem. In that case, you want to prevent people from decrypting content, but they have to decrypt it to watch it, so you have to give them to key anyway.
In your case, you want to prevent people from signing fake scores, but they have to be able to sign real scores, so you have to give them the key anyway.
All you need to do is make sure your scheme requires more effort to crack than the potential rewards. Since we're talking about a game leader board, the stakes are not that high. Make it so that someone using tcpdump won't figure it out too quickly, and you should be fine. If your server is smart enough to detect "experimentation" (a lot of failed submissions from one source) you will be safer than relying on any cryptographic algorithm.
generate a random, something fairly long, then tack the score to the end, and maybe the name or something else static, then sha1/md5 it, and pass both to the server, verify that the random hashes, to be equal to the hash.
After-thought: If you want to make it harder to reverse engenier, then multiply your random by the numerical representation of the day (monday=1, tuesday=2,...)
One idea that might be Good Enough:
Let Secret1, Secret2, Secret3 be any random strings.
Let DeviceID be the iPhone's unique device ID.
Let Hash(Foo + Bar) mean I concatenate Foo and Bar and then compute a hash.
Then:
The first time the app talks to the server, it makes a request for a DevicePassword. iPhone sends: DeviceID, Hash(DeviceID + Secret1)
The server uses Secret1 to verify the request came from the app. If so, it generates a DevicePassword and saves the association between DeviceID and DevicePassword on the server.
The server replies: DevicePassword, Hash(DevicePassword + Secret2)
The app uses Secret2 to verify that the password came from the server. If so, it saves it.
To submit a score, iPhone sends: DeviceID, Score, Hash(Score + DevicePassword + Secret3)
The server verifies using Secret3 and the DevicePassword.
The advantage of the DevicePassword is that each device effectively has a unique secret, and if I didn't know that it would make it harder to determine the secret by packet sniffing the submitted scores.
Also, in normal cases the app should only request a DevicePassword once per install, so you could easily identify suspicious requests for a DevicePassword or simply limit it to once per day.
Disclaimer: This solution is off the top of my head, so I can't guarantee there isn't a major flaw in this scheme.