I am working on an iPhone app that uses CoreData(with SQLite) to stores some sensitive biographical data that is downloaded via a Restful Web Services for offline use in the device.
I am worried that the competition could pay a subscription and extract the .sql file via SSH with a jailbroken device, and make copies of the data that has taken us so long to collect and maintain, and is the foundation of the service.
I was wondering if someone could suggest a way to make it more complicated for them to extract this data. I also store some HTML files with sensitive information in the Resources group that i would like to make harder to extract.
Thanks,
Security by obfuscation almost never works.
You should properly licence your application instead of trying to do this sort of thing. If someone really wants to have access to your sensitive data they will surely find a way to do it.
I would point out that under American and EU law, you can copyright a database i.e. a specific collection and/or order of information, even if the individual units of data exist in the public domain.
It's just like an encyclopedia. A encyclopedia is a collection of facts that belong to no one but the collection of facts constitute something that is copyrightable.
Copyright is the only possible protection against someone who buys access to the data in the software.
You could encrypt the data before your write it to the DB. Note that using encryption may have implications for selling your app in different countries around the world. This
thread might be helpful to you.
The problem with a jailbroken device is that the attacker has more control than you do. There is no place where you can hide information, most importantly encryption keys.
There is nothing keeping your competition from stealing this data if the want to obtain it. You are looking for security though obscurity, and you are wasting your time. Consider a different business model.
Related
I'm trying to figure out how to make an iPhone application allow multiple users (that have it installed) share data among them. Now, the tricky part is that I don't want to host a server at my place (very poor ISP services), so I would opt for an online hosting solution. Next, by data I understand them to be able to, let's say, post a comment that would become readable to all the other users and to see what other users have said.
So, in my mind, I'm thinking of either having a file remotely hosted that could be accessed by multiple users at the same time, or a database of some sort or anything like that.
You haven't given us much to go on -- it's not even clear what your question is. If you're just asking how to go about this, I'd suggest the following steps:
Figure out what, specifically, you want the app to do, what data it will share, and who the data will be shared with. Is this an app that you're going to distribute publicly? Will all users share the same data, or will groups of users share with each other but not outside the group? How big is the data, and how is it structured? Can any part of the data change at any time (like a shared document) or will the data just be updated (like a SMS conversation)?
Decide how you want to host the data. If you'll need to serve a lot of users, you'll want some sort of database. If you'll need to serve a LOT of users, you'll want to make sure that your solution will scale easily. There are lots of hosting companies that provide access to databases like Oracle or MySQL, and that may be enough for your purposes. Or, you might want to look into some of the web services options, such as those offered by Google and Amazon. These can be fairly easy to use and have the advantage that they'll scale very well.
Get to work. You'll probably want to build a very basic version of your app around the same time that you're getting the server side working, so that it's easier to test. Once the server side is working and reliable, you can shift the focus back to building out the rest of your app.
Recently we developed and published a mobile banking app on the app store, for a big banking organization. The bank hired a security firm to perform ethical hacking over the app to see if it, in anyways compromises confidential data.
We recently received the hacking report from the firm, which in-spite of saying that no serious security issues are present, contains a list of all the class files, method names and the assembly code of the project.
Now the client insists that we fix these security loop holes and republish the app. However we don't have any idea how did they manage to get all these details from the application's IPA. I searched this over SO and found a particular post mentioning this link, which states that you can't save your app from being hacked.
Please help me how to fix these security vulnerabilities , or if not possible, how to convince the client.
Edit:
Recently came across this page. Seems like EnsureIT from Arxan can prevent app IPAs from reverse engineering. Anyone experienced with this?
There's always a risk involved. Even if you don't introduce vulnerabilities yourself, the platform may allow for exploits which in the end may offer an entry point for a malicious attacker.
As to your question: It is not safe to assume that a hardcoded URL, even if obfuscated beyond belief, can't be peeled out of your product. Always design your apps such that safety of user data is guaranteed (as far as possible) even if built in ressources get compromised. If the knowledge of that URL alone poses a security threat, then your whole approach and your clients API is inherently insecure. Remember that such information could possibly be captured by a man-in-the-middle attack (and other modes of attack) as well.
Avoid security by obscurity. Store sensitive data only on disk if it is necessary. As a rule don't allow PIN / TAN storage.
Some thoughts which may (or may not) convince your client that your app is as safe as it can be:
As long as the app runs on a non-jailbroken device, it is unlikely that an attacker, even with knowledge of your apps internals is able to get to any user data, because the iPhone normally doesn't offer opportunities to interfer with your app
If the attacker is able to get to your users data, and provided you have been protecting that data with all means available under iOS (-> keychain -> crypto chip ->...), then it's not your fault. It means the device is either jailbroken or there are vulnerabilities to the system itself which have been exploited, you just can't do anything about either possibility.
It is impossible to prevent reverse engineering of your app. Even if you had put more effort into obfuscation, an attacker with strong motivation would still be able to get what he wants. Your client needs to get used to this as it's a fact.
Other platforms suffer from similar vulnerabilities, yet on the iPhone at least you have a somewhat closed environment and a reduced risk of being attacked with trojans and the like.
The governments and security firms get hacked on a regular basis, although they should now how to protect themselves. This means life is inherently insecure, cope with it.
I was recently researching over this and I found this article helpful, especially the part quoted:
The code for a native app is stored in the form of a binary executable file, which is further encrypted; its decryption is performed only when the executable file is loaded by the processor into the random access memory and the whole decryption process happens at the hardware level. That is why it is very hard to create offline decryption tools. The only way to decrypt encrypted binary data is on a jailbroken device with a few special tools installed.
Security in iOS: Protecting .ipa File Content by Stoyan Stoyanov
I've searched the web for this bit to no avail - I Hope some one can point me in the right direction. I'm happy to look things up, but its knowing where to start.
I am creating an iPhone app which takes content updates from a webserver and will also push feedback there. Whilst the content is obviously available via the app, I don't want the source address to be discovered and published my some unhelpful person so that it all becomes freely available.
I'm therefore looking at placing it in a mySQL database and possibly writing some PHP routines to provide access to my http(s) requests. That's all pretty new to me but I can probably do it. However, I'm not sure where to start with the security question. Something simple and straightforward would be great. Also, any guidance on whether to stick with the XML parser I currently have or to switch to JSON would be much appreciated.
The content consists of straightforward data but also html and images.
Doing exactly what you want (prevent users from 'unauthorized' apps to get access to this data') is rather difficult because at the end of the day, any access codes and/or URLs will be stored in your app for someone to dig up and exploit.
If you can, consider authenticating against the USER not the App. So that even if there is a 3rd party app created that can access this data from where ever you store it, you can still disable it on a per-user basis.
Like everything in the field of Information Security, you have to consider the cost-benefit. You need to weigh-up the value of your data vs. the cost of your security both in terms of actual development cost and the cost of protecting it as well as the cost of inconveniencing users to the point that you can't sell your data at all.
Good luck!
I have several plist files in my app, that I want to be non human readable, or editable.
The idea is to encode them using another app, then drop them in the normal iphone app just for decoding and processing.
I have drooped encryption because 1st, I don't need something with strong encryption, and 2nd because of the app store procedure for encrypted apps.
Can anyone suggest me how to proceed? What is the simplest (not the best in terms of encryption) method implement?
Please assist!
iPhone applications are "sandboxed", meaning that applications cannot read each other's data; each application has associated with it its own username and group, along with its own set of folders that it owns. An application cannot access the folder or data of another iPhone application. Therefore, the requirement doesn't really make sense. You should simply use NSDictionary -writeToFile:atomically, and NSDictionary -initWithContentsOfFile to read/write the data to/from a PLIST. If you need to add encryption (because you are worried about two people sharing the iPhone, or something like that), then I suggest you encrypt the individual entries before placing them in the dictionary.
Edit
Based on your comment below, it appears that you are trying to prevent people from pirating your application, rather than trying to protect user data as the question implies. Unfortunately, it is always possible to pirate an application. Anything ranging from obfuscation to using certificates to asymmetric encryption to running a checksum over the application binary can all be bypassed or defeated. The best way to deter piracy is to have a quick iteration cycle and to place most of your data in the cloud, where it is frequently changed and updated, as doing so diminishes the value of any pirated snapshot of the application. That said, it is generally a good idea to consider software piracy as simply a cost of doing business. Most users will not pirate the application, and since all the various methods for protecting your application can (and will) be defeated, the costs of implementing such things is generally not worth it.
Take a look at the NSDataWritingOptions of NSData. There is built in encryption for binary plist files. I've never used it so I don't know how easy it is for someone with developer's tools to defeat it. It should however provide protection against casual thievery.
However, if your worried about about other developers stealing your content, your best protection will be copyright. Copyright protects content, that's what its for. Make sure to include a copyright in the actual plist as part of the data. Stick a copyright in every resource file e.g. images.
I would like to get feedback from all you seasoned developers as to what methodology would be the more "correct" or "efficient" way of implementing my solution.
I have a 4.5 MB flat file that is some 16,000 rows with 13 columns. I know I can import this into SQLite and create my data model but would it be more iPhone efficient to use this file locally on the iPhone or have the application read the data from a web service?
Thanks.
If you are not going to update the data (or only update it when you are updating the app) the local sqlitedb is going to simpler and more responsive. You would probably be even better off importing the data into CoreData, that way you won't need to directly manipulate sqlite or deal with things like synchronous read APIs.
If you want to be able to have the app download updated data the choice because a lot more difficult, depending on the quantity of data, the frequency of updates, how large the changes tend to be, etc.
a local database should always be more efficient in terms of user experience than a web service
I'd use both.
A remote source allowing for a dynamic datastore, and a local datastore with local cacheing seems like a pretty safe bet.
As for the web service. Unless there is any server-side only business logic, maybe give a cloud solution a try. Something like Amazon's SimpleDB comes to mind.
It of course really depends on how static your data is. As everyone has mentioned already if you don't need many updates the most effective solution is a sole local datastore.
Cheers
I guess it depends a bit on how much of the data you need at any one time. If your users need to download a lot of data just to use your application, that would make your app potentially very slow and also unusable without a network connection.
How often do you need to update the data? Frequent updates would favour a web service solution. Otherwise you'd need to update your app and resubmit every time a bit of your data changes.
Another thing to think about: how much do you pay for web traffic for your website? It could become quite expensive if a lot of users constantly need to download data. Unless you use some kind of subscription you only get money once, when you sell the app.
Personally, I'd probably lean towards putting the data on the phone and not using a web service.