How can I privately share data between two apps on the same device that have different team IDs? We used to do this via the pasteboard, but with iOS7 to use app-specific pasteboards they now have to have the same team id.
The problem we are trying to solve is the unlocking of features in one app if the user has purchased another app. We'd like this to happen quietly in the background (hence originally using app-specific pasteboards) but having some security to prevent users from spoofing the process and unlocking features.
One approach we are investigating is to use a system pasteboard but to encrypt the data with a device specific key. As long as both apps use the same algorithm to generate the key this should work, but he problem then becomes how to generate an app specific key.
Any advice/guidance on the best way of enabling this sort of feature unlocking scheme would be very helpful.
I use the pasteboard for sending data between applications as well. It's a really useful tool for sending medium size amounts of data between applications. I actually wrote up a blog post on the topic a while back.
Unfortunately, as you've pointed out, private pasteboards are only available to apps that share the same prefix in their app id. This is typically the Team ID, but may be different if you have an app that dates back to when you could use a different bundle seed identifier.
If you have medium sized amounts of private data being shared between apps with different prefixes then a different solution is in order. In this case I would suggest using some form of encryption and using the general pasteboard to shuttle the data around. Depending on the sensitivity of the data, it probably would be a good idea to encrypt the data even when using a private pasteboard. Rob Napier has a nice library for making the encryption and decryption very simple.
Alternatively, if your data is fairly small you might consider encoding the data into a URL and using a URL scheme to move the data into the other app.
Related
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.
There seem to be a few different ways for an app to store data in iCloud (iCloud Drive Documents, Core Data with iCloud Sync, CloudKit Private Databases, Key Value Pairs etc) but I'm not sure if that's all. Which of these different types of iCloud storage appear to the user in the iCloud 'Manage Storage' menu (i.e. some apps don't appear at all whereas others list 'Documents and Data' whereas others list files that can be individually removed but don't appear in iCloud Drive)? I'm trying to figure out but the documentation's a bit vague on this.
Aaron,
There are three "Apple owned" places you can store data for an iOS device, on the device itself, in an iCloud Drive and/or in the iCloudKit database.
The iCloudKit database has within it three more places. Two of those are databases in the true sense of the word, so structured areas you can store information within, namely key/value pairs and CloudKit. A CloudKit database itself breaks down into two more principle divisions, public and private areas.
Their accessibility is governed on a user/app basis. So you as a developer can opt to use or indeed make your files accessible on them or not. The rules governing who can access what can be confusing, especially as they can/have been changing over different iOS releases.
The iCloud Drive is the most and least flexible, you can store everything on it but you cannot share anything within it, except with yourself.
The iCloud key/pair database comes next, except it is used exclusively by an application to store application state/preferences only [it has a very limited space], again you can share it with yourself only.
The CloudKit database comes next, again something that would be used on an application by application basis. So apps do not share databases and cannot access other app databases, unless they come from the same author and sharing is a built in functionality that has been explicitly intended.
That said, the CloudKit database has two distinct areas a private and a public one. The private area can be accessed by a single user of an app, the public area can be accessed by anybody using said app on any iOS device.
CloudKit documents are an area where Apple store documents from its apps principally, so keynotes, pages and numbers; although they have opened it up somewhat in recent years. They can be shared with other users too using on of the apps designed specifically to store data within the iCloudKit documents area. It is the closest you'll get to a dropbox under iOS, short of using dropbox fof course.
Finally you can store data on your iOS device itself and opt in to share that with others on the same device too thru Apple's files app, although that that is a very recent status quo, so only available for apps designed to run under iOS 11 explicitly opted into the new status quo.
All that said, Apple counts all the places as one in the same when it comes to storage limits, be warned if you want design/build an app using cloudKit storage; if Apple deem you did so recklessly, you won't get a foot in on the app store.
As final comment Apple security policies are designed as a general rule to ensure you as a user have quite fine grained control over who accesses their data, it was/is an intentional decision on their part to protect you from yourself. As a general rule, it works well; which is why you see almost no viruses under iOS.
When we talk about securing iOS application we often forget to secure most critically sensitive information such as secret, key, token, encryptionKey. This information is stored in iOS binary. So none of your server side security protocol will help you.
There are lots of suggestion that we should not store such information in the app but store in the server and get it via SSL secured web service call. But this is not possible for all application. E.g. if my application does not need web service at all.
In iOS app we have following option to store information.
UserDefault: Not appropriate for this case
String Constant: Not appropriate for this case. Can be reverse
engineer to retrieve or just use strings command
Secure Database: Store in Secure and encrypted Database. But again have responsibility to secure database username and password.
KeyChain: Best to store critical info. But we cannot save information before installing the app. To store in the keychain, we first need to open the app, read from some source and store in the keychain. Not appropriate for our case either.
Custom Hash String Constant: Not to directly use secret, token, key from service provider (mixpanel, paypal), instead use hash version of that information from custom key. This is also not perfect solution. But add complexity during hacking.
Kindly send some awsome solution to this problem.
If you don't want to use your own backend then use Apple. You can configure On Demand Resources and keep data file with your key, token, any secret on Apple server. After first download you can write this data to Keychain which is secure enough. I'm guessing networking between iOS and Apple server is also secure enough.
On-Demand Resources Essentials
Accessing and Downloading On-Demand Resources
1) Internet Connection Required
1.1) Push Notifications
Great way to have a secure data exchange could be to use (silent) push services from Apple, those use the apns and send data through https - more Details 3.1
1.2)
A more or less similar approach is also used when distributing new user certificates to already deployed applications, if a reinstall of the application is no opportunity AND the application requires a working internet connection anyway.
Downside: working network connection required and basically the information is coming to the application, when it is already being executed => seems not to be appropriate for your case. (see step 4)
2) Static data (as there will be no exchange without network connection / communication partner)
Encryption of data with private key being provided in the bundle itself. Whether it is now a string or a hash, which can be reverse engineered with functions you got emebedded in your application.
Since iOS9 it is pretty hard to decompile iOS applications and basically you will mainly have a look into the provided header-files. So if you had such a function, string, hash value or whatever, make sure you got it in your .m-file!
But again: if the information is not device or user specific, just a secret across your own micro environment, valid across all devices, you would have to provide the encrypted data AND the decryption method in the same bundle, if there is no update process / information exchange or something else, you can think of.
Good for encryption:
iOS System.Security https://developer.apple.com/reference/security
or simply openssl
The difference between your described keychain approach is:
You got a value, which WILL be encrypted and stored securely.
(2) describes the approach to have an encrypted and stored (in bundle) semi secure value, which WILL be decrypted
3) Information exchange
You describe critical data, which was hashed by another instance. Great! - Make sure, relly make sure, the instance you are talking to is really the instance you expect to be (Network Hooking prevention with ssl certificate pinning etc, but even here you might have intruder (men-in-the-middle)). And you will (probably) have a certificate being provided in your application bundle, to ensure the authenticity of the communication server - here you go again, data that is supposed to ensure a secure process between certain instances of your micro environment. Nevertheless, this data is being provided in your application's bundle.
3.1 Secure Information Exchange extended - Silent Push
Make use of Apple's servers to exchange your secrets for this purpose. If you just need to exchange small data chunks. I would recommend to use silent push notifications to the user, those do even work without explicit permission from the user. Huge advantage: In case your secrets or keys change, you can inform users as soon as possible about the change. They will likely only need the change, when they receive new data, which should reliably work in most cases. Exception: Data exchange in local networks or via bluetooth, in this case I would recommend to provide a notification to the user to have the requirement to update a local decryption key. Or exchange the key in this format as well. Once again: I am leaking some detailed information about your environment architecture.
Downside: You don't know, whether a user just used your app for the first time, until the user "tells" you so.
https://developer.apple.com/library/content/documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/APNSOverview.html#//apple_ref/doc/uid/TP40008194-CH8-SW1
3.1 Secure Information Exchange extended - In App Purchase
Use a frree In-App Purchase for the user to get the data to your phone. Good point here: you can provide larger data chunks easily, as this should be an active request by the user, the user does expect certain processing time and should also be aware of the fact to require a working internet connection.
Downside: User would have to select this on purpose. Up until then the app would not work accordinly.
https://developer.apple.com/library/content/documentation/NetworkingInternet/Conceptual/StoreKitGuide/Introduction.html#//apple_ref/doc/uid/TP40008267
So, it just slightly differs from the approach (2) in its basic idea.
In short: Can you provide additional information, what kind of data you need to encrypt/want to store securely and whether you will have a network exchange or not?
Would need some more information here :-)
I would like to emphasize once again that an application on iOS is not that easy to decrypt anymore, even decompiling would not get everything, you expect it to get. For instance decryption tools like dumpdecrypt were only working properly up until iOS 8.4
It seems to me that the best way to do this is using the built in CloudKit. You can save your secrets in the CloudKit Dashboard and then fetch them on startup. Since CloudKit is only a transport layer you'll have to store the app secrets in the KeyChain.
I know you mentioned the KeyChain not being ideal for your use case (not sure why), but this is a good way of not including the secrets in your app. You can't get around fetching your app secrets from another source.
CloudKit access is secured using the system iCloud account and if there is no iCloud account you still access the iCloud servers securely. Another added benefit of this is that you can change your app secrets at any time, so if you want to be even more secure you can implement a rotation schedule.
Learn more about CloudKit
Cocoapods-keys might be a best option.
From cocoapods-keys doc's
Key names are stored in ~/.cocoapods/keys/ and key values in the OS X
keychain. When you run pod install or pod update, an Objective-C class
is created with scrambled versions of the keys, making it difficult to
just dump the contents of the decrypted binary and extract the keys.
At runtime, the keys are unscrambled for use in your app.
The generated Objective-C classes are stored in the Pods/CocoaPodsKeys
directory, so if you're checking in your Pods folder, just add
Pods/CocoaPodsKeys to your .gitignore file. CocoaPods-Keys supports
integration in Swift or Objective-C projects.
Check out this link for installation, usage and more info : https://github.com/orta/cocoapods-keys
I agree with #Lobsterman and believe that the best way will be to use a combination of these.
Don't include the secret information in the app initially.
Deliver the secret key either as in-App purchase content ,on-demand resource or send it through push notification. This will add the benefit of changing the key periodically if you want and the change will take effect without any additional effort.
Add the entry to keychain access once the content is delivered.
If the data is extremely sensitive then it should never be stored offline on device because all devices are crackable. If you still want to store on device then 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.
I recently have a use case where i need to share huge amounts of data between two iOS apps. The two apps can have different app id prefixes. What could be the best ways to do it?
I have explored some of the options but either some of them need a common app id prefix, some are not very secure and some require additional user interactions.
Suggestions, thoughts welcome. Thanks!!
I have explored the following options -
UIDocumentInteractionController
UIActivityViewController
Both of these I can't use because I do not want to have additional user interaction.
Shared Keychain Access - This cant be used as the apps can have different 10 digit seed prefix
I was contemplating on using URL Schemes but I wonder if there is a limit to the amount of data that can be passed using URL scheme.
I also got to know about DocumentProvider extension with iOS 8 but did not get a clear picture on whether it will also involve additional user interaction or not. Also, is it mandatory to use iCloud with DocumentProvider.
To my knowledge, we have following ways data can be shared across two different iOS applications:
UIDocumentInteractionController
UIActivityViewController
Shared Keychain Access
Custom URL Scheme
Web Service
For sharing large amount of data, Web Service based solution makes sense but with an overhead of web service implementation and availability of network.
I know there are quite a few threads on this, but it seems none of them would satisfy what I am trying to look for. Here's my constraints:
not a hack that uses private API/framework or undocumented
directory access that would run the risk of app being rejected
because of that
being able to share data across different
vendors / app developers
data can persist outside the lifecycle
of the app (even after app is deleted)
UPDATED: I was in general trying to stay away from using a 3rd party cloud-based service to achieve the goal as this would introduce additional external dependency. But if I have to, I was hoping it could satisfy this one constraint
being able to tell which iOS device it is communicating with. It shouldn't have to uniquely identify the device (which will go into that evil UDID discussion route as we all experienced ). But as long as it can differentiate among different iOS devices it should be fine.
I kind of need this too. I use Parse.com as the backend of all my apps — their free tier should satisfy your development needs.
Parse has APIs available for iOS, Android, Windows 8, OS X, JavaScript and .NET, with all your data available on the cloud on any platform (contrary to Core Data and iCloud). They also offer "Cloud Code," which is code you can execute remotely, to process information remotely and get the data back to your app.
You should definitely check Parse.com out for cloud storage for your app. In my experience, it really gets the job done.
For Data Persistence, I think you might want to take a look at FMDB (although if you decide to persist data locally, it will get deleted with your app, but it might help you, anyways). Core Data is an overkill in many cases.
Edit: Parse.com has an "Installation" class, in which all the devices that have your app installed get listed (wether they're running iOS or Android), uniquely, without you having to type any code.
Maybe this blog post by TextExpander authors will help:
Smile has responded to this by discussing the issue with Apple
engineers at WWDC, filing a bug (#14168862), and checking up on the
status of that bug. We also developed a workaround by storing the
TextExpander data in a new place. Reminders requires user consent to
store and retrieve data. Completed reminders are not normally shown in
its interface. Long-past reminders appear at the bottom of the
completed reminders.
TextExpander touch 2.1 (and later) supports storing shared snippet
data in a long-past, completed reminder. We produced an updated SDK
and kept our developers posted on its progress. Our final SDK was
ready within a few hours of the end of Apple's official iOS 7
announcement.
UPDATE (22.11.2013)
This might not be the best way to do that, because TextExpander's team recently had problems with the App Review Team.
Edit: this only works for apps with the same vendor.
You can save a password to the device's keychain, then access that password from any app.
Using the SSKeychain library...
NSString *service = #"com.yourcompany.yourservice";
// read
NSString *password = [SSKeychain passwordForService:service account:#"user"];
// write
[SSKeychain setPassword:password forService:service account:#"user"];
The password string doesn't have a length limit, so encode all your data as a string and save it there. The keychain entry will persist after the user deletes the app.
One of the ways to do this is using THRIFT. This is a data communication protocol that would need a back end server (private) and THRIFT can be compiled into many languages / platforms. There is a meta language to describe the data and then can be thrift compiled into many languages. Write the data definition once and can be used on many platforms.
More information at.
http://thrift.apache.org/
for me (I have 2 apps and a widged) the best solution is using SSKeyChain and do not forget to add Capabilities for your apps like here
or if you don't wanna to use 3rd party library you can use NSUserDefaults and set the group identifier like here but again do not forget to add the group identifier in Capabilities in AppGroups section for all your apps that have share data.