I'm creating an app that relies quite heavily on Core Data. It is a content-driven app that primarily delivers question/answers to the user.
On its first load, the app delegate pulls through lots of data from an SQLite into the app's persistent store. The data is basically lots of content that is not only in-app purchasable, but is also copyright-protected.
Normally, developers requiring encryption/protection for Core Data need it for storing sensitive user-data. However, as in this (my) case, I would need to protect the persistent store from external access from anyone or any source (including the user), purely due to the fact that I don't want someone to be able to download the app's entire Intellectual Property from the persistent store.
I noticed on the iPhone Simulator that locating the persistent store and opening it (with an SQLite browser) was no trouble at all. This is a little worrying, and so, if this is also as easily possible for a release installation on a device, then I would like to know:
I don't necessarily want to go all-out on encryption, as I've found ways to do this row-by-row (lazily), so is there a quick way to obfuscate/scramble a persistent store?
This article shows how to encrypt individual attibutes(of course you can encrypt all attributes).
Related
I'm working on a game-companion app and I was looking for a neat way to fetch data from multiple APIs initiated by starting my app (and maybe also if the user is refreshing the current page with swipe-to-refresh).
The thing is, I planned a dashboard-style homescreen (mostly reduced data from every API), where the user can navigate to different pages (all fed with different API's) and get detailed information for the specific section. I'm not sure how I can provide the API-data 'globally'.
I feel like my main.dart would be way too overloaded, but i can't think of any other way.
What's your thought on that?
Few approaches:
You can use a persistent db and write a wrapper DAO over it that such that anybody with access to this DAO object can write and read from DB. Packages like sqlite help in this regard.
If you are adopting bloc way of state management in your flutter app, then you can create blocs which could be used to share data across your app. flutter_bloc is a good place to start with this.
Via Singleton , If you want a sensitive data that needs to be available within the app globally, then you can create a singleton class that provides read and write from a secure vault. For this secure vault, flutter_secure_storage is convenient or shared_preferences for non sensitive data
Let’s say I have a client who has spent a lot of time and money creating a custom database. So there is a need for extra data security. They have concerns that the information from the database could get scraped if they allow access to it from a normal web app. A secure login won’t be enough; someone could log in and then scrape the data. Just like any other web app, a PWA won't protect against this.
My overall opinion is that sensitive data would be better protected on a hybrid app that has to be installed. I am leaning toward React-Native or Ionic for this project.
Am I wrong? Is there a way to protect the data from being scraped in a PWA?
There is no way to protected data visible to browser client regardless of technology - simple HTML or PWA/hybrid app.
Though you can make it more difficult.
Enforce limits on how many information a client can fetch per minute/hour/day. The one who exceed limits can be blocked/sued/whatever.
You can return some data as images rather than text. Would make extraction process a bit more difficult but would complicate your app and will use more bandwidth.
If we are talking about a native/hybrid app it can add few more layers to make it more secure:
Use HTTPS connection and enforce check for valid certificate.
Even better if you can check for a specific certificate so it's not replaced by a man-in-the-middle.
I guess iOS app would be more secure then Android as Android is easier to decompile and run modified version with removed restrictions.
Again, rate limiting seems to be the most cost effective solution.
On top of rate limiting, you can add some sort of pattern limiting. For example, if a client requests data with regular intervals close to limits, it is logical to think that requests are from a robot and data is being scrapped.
HTTPS encrypts the data being retrieved from your API, so it could not be 'sniffed' by a man in the middle.
The data stored in the Cache and IndexedDB is somewhat encrypted, which makes it tough to access.
What you should do is protect access to the data behind authentication.
The only way someone could get to the stored data is by opening the developer tools and viewing the data in InsdexedDB. Right now you can only see a response has been cached in the Cache database.
Like Alexander says, a hybrid or native application will not protect the data any better than a web app.
I am making a mobile app using Cordova and I need to save some sensitive and not so sensitive data inside the phone. I am a bit lost on what is the best way to do it.
I need to save:
A JSON web-token (for authentication).
A response from server (I save this to populate my page in case the GET request fails).
Coordinates information when user is logging data to the app (for later upload to a server from with in the app). These will be many separate logs, and can be large in size for local storage ~5-10 MB.
Till now i have been successfully saving everything I need to the local storage but I don't think that is the correct way to do it. So that is why I need some help in deciding what is the best course to take from security point of view.
Saving server response is just for better UI experience and static in size so I guess local storage is a good option to use.
But web-tokens and GPS logs is sensitive information and I dont want to keep it in the local storage as it is accessible from outside the app.
What other options do I have?
Cordova still doesn't have encrypted storage.
Is saving to files a good approach? This here says that data contained inside cordova.file.applicationStorageDirectory is private to the app.So can I use it to save the logs and the token?
The plugin also lists the file systems for Android and iOS and lists which of those are private.
I am currently working with android phones but want to extend the app to iOS later. I have never worked with file systems and caches before so I am a bit lost.
How does the Dropbox Datastore API differ from similar offerings like Parse? One difference that I see is that my users pay for server storage instead of me. Are there other differences?
Disclaimer: I'm a Dropbox engineer who worked on the Datastore API, and know about the Parse API only indirectly. Weigh my opinion appropriately. Major differences I know of (pro and con):
Dropbox Datastores are free to the developer, and free the user for the first 5MB per-app (after which their Dropbox quota applies). Parse charges developers based on how many API requests they’re making.
Parse has minimal offline support, while Dropbox has full offline operation. With Dropbox, if the developer modifies data while offline, those modifications will be reflected in subsequent queries (with Parse, those changes are not reflected). Dropbox provides on-device query logic (unlike Parse) so that apps can continue to generate the views they need to, even when there’s no Internet available. In addition, Parse does not provide conflict resolution or querying offline.
Parse provides the ability to share data between users, and global data for all users of the app. Dropbox Datastores only support per-user data (for each app) for now (sharing is on the roadmap).
I would also add that:
Parse is full feature of backend of as service. You can find a pretty complete list of the other player in this field: http://en.wikipedia.org/wiki/Backend_as_a_service. They provide feature like:
Data service
User registration/auth
Push notification
Social
The dropbox Datastore APIs is more focusing on data services. (You also got the User part for free too?) Also it works full offline.
The Parse framework can store data that can be ready by any user in the application.
The Dropbox datastore, store data for each user, and you can't accesss data from other user. That's the main difference.
So easy to get lost in this since you have to read between the lines. My take is that with Datastore you are working with objects stored offline locally as json. I'm hoping they will soon release a Xamarin Android component - they released an IOS component last month. Since Xamarin targets both Android and IOS and Winphone, who knows why they made a dedicated IOS DLL for Xamarin but I digress. With Parse, it appears to me their intent is the always-connected-device. Sure you can save queries locally and you can save (save eventually) locally where Parse will push to the server when it is connected. But saving "eventually" and saving queries for offline work is a different design than just saving and letting Parse do it all in the background for you - which it does not unless I have missed something that would make this attractive to me. I cannot see Parse useable for devices that you know will be sometimes-connected, without a lot of code to make this happen and sync.
I need my native iPad application to store its data (say .DOC documents downloaded via HTTPS) in an encrypted form. Those .DOC files are to be opened in 3rd party apps on the iPad.
I need to know whether there is a way that data of both my application and those of 3rd party apps can be encrypted? Meaning that my .DOC file will never be stored in unencrypted form on the device. (motivation here being that my app downloads documents with sensitive information and I want those documents to be read on the iPad, but with the layer of disk-encryption protection.)
I was reading through Advanced App Tricks # apple.com, section "Protecting Data Using On-Disk Encryption", but was unable to find any relevant information.
First, let's get the hardware encryption aspect out of the way:
iOS supports hardware encrpytion of everything on the disk. It's encrypted with a key that has nothing to do with your device pass code. This feature is there to allow quick wiping of the device's data (by overwriting the device encryption key). It doesn't really protect your data from being retrieved by a skilled interloper who can get your device, however; a jailbreak will get around this.
Per-file encryption via the Data Protection API: iOS can be told that certain files are to be encrypted by setting a flag on them. They are then encrypted using the device pass code (if one has been set). Note: if the user hasn't set a passcode, this extra protection isn't applied! Therefore, technically, this protection is out of your control, unless your users work at an organisation that enforces passcode lock policies (using iPhone Configuration Utility or similar).
Encryption using CommonCrypto: you can use encryption APIs such as this to manually do your own encryption/decryption. Note that if you don't know what you're doing it's easily to abuse such APIs and end up with not very secure encryption. However, there are some wrappers such as RNCryptor which make it much harder to abuse these APIs.
Protecting files used by third party apps: Can you clarify how your app will share files with third party apps please?
More info:
http://support.apple.com/kb/HT4175
http://www.ilounge.com/index.php/articles/comments/ios-encryption-and-data-protection/
http://developer.apple.com/library/ios/#documentation/security/Conceptual/cryptoservices/Introduction/Introduction.html#//apple_ref/doc/uid/TP40011172-CH1-SW1
https://github.com/rnapier/RNCryptor
Update
On using UIDocumentInteractionController:
Once you've handed off your document to another app using this method, the data is out of your hands and the third party app can do what it likes with it. If you're happy with that, and your main concern is just having the document stored on your device in a protected way, then there are a couple of possibilities:
Rely on Data Protection API to protect the document on-disk (user has to set a passcode and you need to tell iOS that the particular file is to be protected for this to work)
Using the NSURLProtocol trick mentioned here to decrypt an encrypted file on disk on-the-fly