secure data persistence of string array - ios

I am displaying a list of images in collectionView. Those images are stored in an array of strings and are available only if user previously bought them as an IAP. The next time the user launches an app, newly bought images should be available to the user. I am wondering, what is the appropriate/secure way of saving such an array? It should be secure and hacker proof. Could you guide me in the right direction?

Images compiled into the app are part the bundle and as such can not be modified due to permissions and signing. There is no reason to put them in NSUserDefaults and that is a poor storage place for many reasons. On a Jail Broken iDevice most security is bypassed.
It they were to be encrypted the app would need the encrypting key and that is problematic since it needs also to be available to the app.
It is veery difficult to secure anything from the device owner.

Related

Is data stored in iCloud using Key/Value accessible by users?

I have an application that is implementing storage using Key/Value pairs in iCloud. From what I read in the documentation this is almost identical to the way NSUserDefaults work.
However this potentially creates a problem because the user should not have the ability to tamper with the app data stored in there. Does this mean that the user can access this data and modify it? Or is it private to the application?
Okay reading deeply in the documentation it says
If your app needs to store passwords, do not use iCloud storage APIs
for that. The correct API for storing and managing passwords is
Keychain Services, as described in Keychain Services Reference.
I found this text here just one line before the last table :)
I also found somewhere that the user can delete his iCloud data manually which can be counted as a modification.
Also, read here, section fro "Start Fresh If Your iCloud Data Becomes Inconsistent During Development" where it says how you can clean the container. Maybe you can check what is visible inside.
It depends what type of data you are storing in the iCloud if it's sensitive then I would use keychain services approach and avoid storing sensitive information on the iCloud.
From the question it seems like you are storing the data in key-value pairs, usually, it's recommended to store preferences, settings, and simple app state and that should be ok because the user can change those, you should choose the right iCloud API for what you want to store
With iCloud the user can always delete the information it has stored as mentioned in the documentation
There may be times when a user wants to delete content from iCloud.
Provide UI to help your users understand that deleting a document from
iCloud removes it from the user’s iCloud account and from all of their
iCloud-enabled devices. Provide users with the opportunity to confirm
or cancel deletion
When you ask
Or is it private to the application?
There's an iCloud identifier in your entitlements file. If it's the same in both apps you'll be able to access the same data/documents across both the apps.
Hope that helps.

Share iCloud Key-Value Storage with app from other Developer

The question might seem weird (and stupid) at first, but keep reading...
I used iCloud Key-Value Storage in one of my apps and now I need to Transfer this app to another Developer Account. But it's, for some reason, impossible to transfer apps if they've used iCloud Entitlements (why no warning?!?!).
So...In other words, I need to remove my original app and create a new one in my new Developer Account. But before that happen, I want my existing users to be able to sync their data to a common iCloud Key-Value Storage, but directed at the new app "container".
If, the "new" app is Live, would it be possible to point at that app Cloud Container (from my old one)? (e.g. my old app saves iCloud data to the new container).
When reading my own question I just think "this sounds like a big security breach if possible", so my guess is, no. But there's nothing in the Apple Documentation that says that this is not possible.
I'm not interested in solutions that involves users saving data on an external db (I know this is possible, but not what I'm looking for right now). Is there some way to save the data locally on disk (without being removed when app is removed) and then read it from the other app?

Saving sensitive data securely in swift

I'm making an app in which I need to save an array of type [Card], where card is the struct:
struct Card : {
var image : UIImage? = nil
var name : String = ""
var titles : [String] = []
var data : [String] = []
}
What is the best way to persist this array considering that it contains data such as credit card numbers?
Would it be enough to enable Data Protection under the Capabilities tab in XCode? At the moment I'm saving using Codable.
There is no right answer to this, but it's a great way to see how much a person has dug into iOS security. If you're interviewing with a bank I'd almost definitely expect someone to know something about it, but all companies need to take security seriously, so here's the ideal list of topics I'd expect to hear in an answer:
If the data is extremely sensitive then it should never be stored offline on the device because all devices are crackable.
The keychain is one option for storing data securely. However it's encryption is based on the pin code of the device. User's are not forced to set a pin, so in some situations the data may not even be encrypted. In addition the users pin code may be easily hacked.
A better solution is to use something like SQLCipher which is a fully encrypted SQLite database. The encryption key can be enforced by the application and separate from the user's pin code.
Other security best practices are:
Only communicate with remote servers over SSL/HTTPS.
If possible implement certificate pinning in the application to prevent man-in-the-middle attacks on public WiFi.
Clear sensitive data out of memory by overwriting it.
Ensure all validation of data being submitted is also run on the server side.
Sensitive data is not necessarily more secure in the cloud than on a device. Devices can be lost but most data breaches occur with data stored in the cloud. A large database of credit card numbers is a much more attractive target than a single persons credit card information stored on a device. Also, it is quite difficult to recover data from a properly secured iOS device (according to the FBI at least).
That said, any iOS app storing sensitive information should have it's own layer of security above that offered by the device including it's own user authentication process.
Disregarding the numerous reasons not to do this, a good way to securely store local data on iOS is trough the Keychain. It's encrypted with your passcode by the device, is preserved for your app even if it is un-installed, and syncs between devices. The API is kind of hard to understand for beginners, so a wrapper such as https://github.com/kishikawakatsumi/KeychainAccess is a good tool to get started.
In Order to save our apps sensitive data, we should use Security services provided by Apple.
Keychain Services API helps you solve these problems by giving your app a way to store the small amount of user data in an encrypted database called the keychain.
In the keychain, you are free to save passwords and other secrets that the user explicitly cares about, such as credit card information or even short sensitive notes.
You can refer this link for a detailed description of using Keychain Services API.

keep corporate app alive in background

I am developing a corporate app that will be publish on an internal store.
The app is just supposed to keep in memory some credentials but I can't store them on the device for security reasons.
I want the app to stay in background as long as possible but I don't know what is the best solution knowing that I won't have to publish the app in the AppStore.
I read about the option in plist Required background modes, but I don't know which option is the most efficient for my situation.
Firstly, you don't need to keep running app in background, second you can store "those [secret] credentials" in keychain store with some encrypted format, SHA1 or MD5 or any other cryptographic hash functions can be use for this, third the benefit of this is you can access to them from your different apps as well (by using the same encryption key to decryption and accessing keychain store item), at last when you no longer need it, you can even delete it. The only thing you need to keep secret is keychain store key (which you used to store credentials) and also your encryption key (to used with cryptographic hash function).
There's are several libraries available to easily manipulate data in keychain store, here's the one, and here's the solution to apply MD5 or SHA1.

iOS: Storing user registration details

I an building my first iOS application and I need to store the user registration details of the user using the application. The details include his mobile number and a unique id( uuid ) which I use to contact with the backend. It would be great if I could get a suggestion on where to store this user details.
Should I be storing this in the NSUserDefaults or should I be using Keychains to store this data or even may be a using a user model in the database ( I would need a database in any case to store a few other details ). Just to add on, I also would like to perform a few validations like if the mobile number is of proper format and so on before I could actually save it. Also can any one please suggest on the security aspects of different storage mechanisms possible here?
Any help on this would be much appreciated.
The most secure way would be to use keychain services as the data is encrypted but in your scenario it seems a bit over kill. I would recommend either just using NSUserDefaults or an sqlite database I wouldn't really recommend storing in a plist as this can be accessed really easily.
But this all depends on the data you are getting, if it was just uuid and mobile number then NSUserDefaults would do probably, whereas if you were getting usernames and passwords and other personal data I would looking a mix of keychain and sqlite database.
Also you could use coredata file to store user data but seems a bit over kill as well for for such little data.
Just a little note you are actually not allowed to get the iPhones mobile phone number programmatically, getting this would use Private APIs that Apple would reject your app for using.
2.5 Apps that use non-public APIs will be rejected
So you would have to ask he user for this.
Database selection is totally depend on the architecture and security, if you just need to store the few information like login details and some field then Keychain for login details and plist for data is best option, but if your application also working with services and fetching and saving lots of data and continuously updating it then a serious database structure required. In that scenario core data and sqlite both are good option depends on your preference
Following ways you can save details.
In NSUserDefaults
In coredata file.
In sqlite database
Plist file.(Not recommended)
You can save data at server site using webservice.
Any one of these you can use according to your requirement and data.
Cheers :)
If you store information on the UserDefaults, a jailbroken device can see the information you have stored, it is a plist after all. If you are going to keep sensitive data on your device, user defaults itself is not a good option. Possible alternatives:
Use keychain: Keychain is a tool to keep usernames & passwords securely on a device; so you may need to find a way to convert all the info you have mentioned ( a dict, I presume? ) into NSData and put into/get from the keychain but it's been explained on other threads. Additionally, keep in mind that when the app is deleted, keychain data will persist on the device.
UserDefaults & encrpytion: If you can encrypt the data yourself, than using UserDefaults might be a better option. Its more straightforward than keychain and it will be deleted if you delete the app from the device (which may be the thing you want, or not. It depends)

Resources