Health related data for a user is a privacy thing and its need to be very secure i.e. it needs to be stored in secure place. For example, while I was watching Apple's official video on Finger print unlock, they told that finger print data is stored at place where it is impossible to hack. So, for a curiosity, I have a question in mind that where these data are securely stored?
I have had a look at this link from Apple Documentation but could not found the information on it. One thing I have figured out is that data are encrypted and stored but where?
Does anyone has idea on the same?
Apple describes the security attributes of various iOS features in this document. To quote:
This data is stored in Data Protection class Protected Unless Open.
Access to the data is relinquished 10 minutes after device locks, and
data becomes accessible the next time user enters their passcode or
uses Touch ID or Face ID to unlock the device.
Read the "Encryption and Data Protection" section of the document to learn more about Data Protection. Any app can use the "Protected Unless Open" data protection class for its persistent data.
As you already know, NSUserDefaults is simple and effective for saving small, simple bits of data, like NSNumbers or NSStrings, to your device’s file system. But this data is in no way stored securely as hackers can access it pretty easily from the device.
You have figured out that sensitive data are encrypted. But you need to find the answer where it need to be stored. The Answer is:
Keychain Services:Apple has provided the Keychain Services API to deal with this problem and help developers build apps that safely handle passwords and other sensitive information.
Now the question might rase why?? and the answer is:
Keychain is great because data encryption automatically is taken care of before it is stored in the file system so there is no need to waste time building encryption algorithms.
You can go through this link for better explanation.
https://developer.apple.com/documentation/security/keychain_services
Related
I am building a fitness app with HealthKit integration. Ultimately I would like to use CloudKit as well to a) allow data redundancy, but mainly b) to provide a few social features which require data to be in iCloud at least temporarily.
I would like to be able to rely solely on HealthKit for data within the app, but feel that an alternate data model is necessary to persist data incase HealthKit permissions are revoked or not given in the first place. I have chosen to stick with Core Data for this.
My question is how do I go about keeping my Core Data store and my HealthKit store in sync. I have searched for an example on GitHub and for related questions on here, but cannot find any useful examples.
Ultimately I will be then syncing the data in Core Data with CloudKit, but is the Core Data intermediary really necessary?
With regards to App Store Review Guidelines 27.3
Apps using the HealthKit framework that store users’ health
information in iCloud will be rejected
I take this to mean that any Health data which was not created by your app cannot be stored in iCloud. There are many apps which store Health data on a third party server (i.e. RunKeeper). Also, without HealthKit permissions I would be allowed to store health data created by my app in iCloud. If you take third party data from HealthKit and try to put that in iCloud, then you'll be rejected.
There's a couple questions in here, so I'll try to answer them in order.
...how do I go about keeping my Core Data store and my HealthKit store in sync?
So there are two application modes you need to worry about for getting data updates: foreground and background.
When in the foreground, you can utilize HKObserverQuery which provides a decent amount of flexibility in getting the data you need. The usual caveats apply when passing data across thread boundaries (as observer queries run on background queues). Pertinent docs: HKObserverQuery Docs
In the background you have to register for background wakeup using enableBackgroundDeliveryForType(_:frequency:withCompletion:). This will wake your application at (or close to) the specified frequency, at which point you'll need to jump through whatever necessary hoops to load your Core Data stack and do your updates. Pertinent Docs: HKHealthStore Background Handling Docs
...is the Core Data intermediary really necessary?
No, and in fact using Core Data may be complete overkill for your uses. I generally recommend against implementing Core Data at the outset of an application. There are performance concerns, background wake concerns, schema migration concerns when you change schemas, and iCloud <> Core Data synchronization issues (most of which have been resolved as of iOS 9 but still crop up occasionally).
On top of all that, Apple's "template" for including Core Data in a new project generally doesn't follow best practice guidelines for integrating Core Data. Do some Google searches and take a look at Marcus Zarra's books on the subject.
That all said, not using Core Data means having to write a bunch more code to enable iCloud to synchronize with your data store of choice, so it's tough to offer a suggestion as to the "correct" route to take.
I take this to mean that any Health data which was not created by your app cannot be stored in iCloud.
Incorrect. Take the line at face value. If Apple sees you've requested access to HealthKit and have provisioned iCloud access, you're probably going to get scrutinized and most likely rejected. They are very touchy about user privacy in this regard, and correctly so in my opinion.
Your note about Runkeeper, while accurate, is also flawed as Runkeeper (last I checked) does not use iCloud and so wouldn't be subject to this, so the analogy is flawed. Also, as per Apple's other guidelines, whatever other apps do or don't do has no bearing on your application's review status.
In short, I would steer clear of storing users' health data in iCloud. Use another provider or your own server.
This is from Apple docs:
When you design a game that reports scores to Game Center, you should
also consider the security needs of your game. You want scores
reported to Game Center to be an accurate accounting of how players
are doing. Here are two suggestions:
Store your game’s preferences and saved games in a secure format,
rather than in clear text. If your game’s data is stored in clear
text, a player can download the saved game data using iTunes, modify
it, and resync it back to the device. This may allow the player to
achieve a higher score than you intended. Always set reasonable
minimum and maximum values for a leaderboard.
I know that data can be stored into .plist file or .xml or .json, even in a database. But all of that is non-encrypted plain text. What is considered as a secure format ? And what else methods/classes/techniques can be used to store sensitive data ?
If a hacker is determined enough and has the proper skill set, your stored data can be usually compromised regardless of storage method. It boils down to what your app's real-world applications are and the time and effort you are willing to put into keeping the data safe. Below are some options for you to consider:
NSUserDefaults
One of the most common and simplest ways to store data. Data is not encrypted.
Save string to the NSUserDefaults?
Plist Files
Also a common way to store data. Data is not encrypted.
Storing and Retrieving from a Plist
CoreData
Creates a model, manage relationship between different types of objects. By default, data is not encrypted.
http://www.appcoda.com/introduction-to-core-data/
http://www.raywenderlich.com/85578/first-core-data-app-using-swift
Keychain
Arguably the most secure way to store data on a non-jailbroken device. Data is encrypted.
https://stackoverflow.com/questions/16459879/how-to-store-a-string-in-keychain-ios
NSCoding
As Whirlwind pointed out, this is yet another storage method.
http://www.raywenderlich.com/1914/nscoding-tutorial-for-ios-how-to-save-your-app-data
http://nshipster.com/nscoding/
CommonCrypto Apple Framework
Low-level C coding. Data is encrypted.
https://developer.apple.com/library/ios/documentation/Security/Conceptual/cryptoservices/GeneralPurposeCrypto/GeneralPurposeCrypto.html
https://developer.apple.com/library/ios/samplecode/CryptoExercise/Listings/ReadMe_txt.html
Custom approaches
Store the data in the cloud thereby eliminate having it on the device altogether. Use the touch ID feature to authenticate the user and download the cloud data.
http://code.tutsplus.com/tutorials/ios-8-integrating-touch-id--cms-21949
https://developer.apple.com/library/ios/samplecode/KeychainTouchID/Introduction/Intro.html
The safest place to store your data is in the keychain, however it's still not 100% secure if users are on jailbroken devices. Follow Apple's guidelines on setting minimum and maximum values for a leaderboard.
Here's another SO post describing how you can store the information in an NSDictionary as NSData which is then encrypted and decrypted by your app.
I know Apple will reject apps that backup data that can be reloaded from the app bundle. However, in the app I'm working on, we'll be providing some basic data that users will want to keep in the Core Data store along with the new data they have created and entered. So, users will use the "library" data we provide by integrating it with their own data as they work with the app.
My concern is whether Apple will require me to segregate these data in some way such that data from the bundle is not backed up to iCloud? Once the data are co-mingled, disaggregation would be complex and burden the app excessively.
So, my question is whether I have to concern myself with the co-mingling of user data with that data which is supplied in the app bundle?
TIA for any input on this as I've not found anything about it in the docs.
I had a similar situation in my app. It has sample data, but the sample data is designed to be edited by the user, and has metadata attached to it that is user specific. In other words, the data is mutable, and belonged with the rest of the user's personally created data.
At one point, the app was rejected. I first appealed to the reviewer, explaining that the data was mutable, and personal to the user — it would not be possible to reproduce the data purely from the app bundle. The reviewer would not budge, so I appealed, and they sided with the reviewer. Game over.
You may be able to get away with a small amount of data loaded from your bundle (<1MB). If you plan to include images or anything that will push up that amount, they will likely reject you.
I also heard from another developer rejected for including data downloaded from a web service in the user's store. Apple claimed that the data could be re-downloaded, which may be partially true, but ignores the fact that the web service was operated by a third party, and the downloaded data could be unshared at any time. It also ignores that the user can edit the downloaded data, and that the client app is attaching user-specific metadata that cannot be downloaded.
That developer was rejected as well. He eventually got the app through review by introducing a complex set of procedures to import the data: the user had to first download the data to a temporary holding area that was not backed up. They then had to explicitly import the data, and dismiss a wordy dialog warning that the imported data would contribute to their iCloud backup quota. Horrible. But that is apparently what Apple wants.
The rule is pretty mindless, in my view, and Apple seem to be completely oblivious to the implications in terms of user interface changes and drastic refactoring of an app's model. I can't imagine any engineers were involved in forming the rule, because they surely would have realized how much unnecessary complexity it would impose on developers. We can only hope they see reason at some point.
I want to use core data to store data which I am getting from APIs, and this data is for banking so need to be more cautious. Actually I am newbie in Core data so I am bit confuse about my clients requirements, following are requirements and question.
Client mentioned in email that "We will need to keep everything in memory (never write to disk)", so what is usage of coredata?
"We would only use a single store of type NSInMemoryStoreType; i.e. never use Sqlite or any other mechanism that writes to disk". is This the way we can achieve to store in memory?
As cleint mentioned in Note that "This is a requirement of the bank - because we will be parsing sensitive customer data we can not ever write it to disk"
Kindly give me suggestion or any reference link for how to achieve this target. Looking for response.
Thanks.
Yes, you can set PersistentStore with NSInMemoryStoreType, and then data will be only stored in memory, not disk-based persistent store such as SQLite. The more details visit https://developer.apple.com/library/ios/documentation/Cocoa/Conceptual/CoreData/Articles/cdPersistentStores.html#//apple_ref/doc/uid/TP40002875-SW3
We need to store various data (accesstokens, receipts). In bytes this is relatively small (20000 symbols or so).
We don't want the user to be able to read and tamper this data because we to some extent don't want any smart users to bypass our systems in some way.
We don't want this data to be stored after app is deleted. Therefore keychain seems inappropriate. This is wanted because it seems sensible that the user should get a clean install every time they install the app.
If you want to have the data secure you should use Core Data with apples Data Protection on the DB file.
In addition to that you should encrypt the data itself too.
UPDATE:
You may want to give this a look for encrypting the data: RNCryptor
And this for Data Protection: Data Protection