Is there any way to make directory in iOS secured and protected just for my app?
in my application user buys books and I save books on documents sub directory, so I don't want any other application to access this directory
any suggestions ?
should I encrypt this data ?
The documents folder is indeed sandboxed from other apps, but it is not safe from 3rd party utilities which lets you check the iPhone's file system (jailbreak not required) , such as iExplorer.
If you want to secure your app data you should read about the data protection api's in Apple's developer portal. There's a nice WWDC lecture as well (I think its from 2011).
Another solution could be packing your material in a secure format , such as an encrypted zip file (some sort of password derived from the device's uuid you create on the spot).
You may be interested to take a look at Data protection for iOS:
http://support.apple.com/kb/HT4175
What are the new "iOS data protection APIs"?
Data Protection on iOS
Implementing and Testing iOS data protection
The documents folder for your application is sandboxed and can be utilized only by your application. If you are storing resources to be used by your app, this is the place to put them.
Related
I need to create an integration between my app and apps by another developer. There are several ways to store data for an app, some that allow only your app to access it, some that allow other apps by the same developer to access it. But is there an iOS API that allows you store data publicly on the device so that any other app can access it? This data is not secure and cannot be used maliciously.
May not work for your specific needs, but note you can share documents between apps using UISupportsDocumentBrowser. See also here.
UISupportsDocumentBrowser (Boolean - iOS) Specifies that the app is a document-based app and uses the UIDocumentBrowserViewController class.
If this key is set to YES, the user can set the document browser’s default save location in Settings. Additionally, the local file provider grants access to all the documents in the app’s Documents directory. These documents appear in the Files app, and in a Document Browser. Users can open and edit these document in place.
This key is supported in iOS 11 and later.
This would violate iOS security policies and is therefore not possible on device. The only way to enable this is on a jailbroken device.
I have a free version of an app and a paid version. I'd like to give users the option to import their existing data from the free version into the paid version.
Currently the data is stored in Core Data.
I've looked at existing solutions across the internet and SO, the existing solutions suggest making a request from the free application to the paid application using a URL request that contains the data. (e.g. http://mobileorchard.com/lite-to-paid-iphone-application-data-migrations-with-custom-url-handlers/)
So my question is, how is best to implement the solution in Swift:
Is the URL method still the best approach?
Are there any code samples available?
One idea I've had is to convert the entire DB to JSON, then to make a request with the JSON payload and deserialise it into Core Data the other side. Create json string from core data and vice versa?
What I'd do is set up an app group that both apps can access. Put your data in the app group folder and access it from both versions. You don't need to copy it, just leave it where it is.
To do this:
Set up an app group in the "App Groups" section of the target settings in Xcode. Use the same app group for both versions.
Find the location of the app group folder with:
NSURL *groupURL = [[NSFileManager defaultManager]
containerURLForSecurityApplicationGroupIdentifier:
#"GROUP_NAME_HERE"];
Or in Swift:
//swift
let groupURL = NSFileManager.defaultManager().containerURLForSecurityApplicationGroupIdentifier("groupIdentifier")
Modify your Core Data setup code to put the persistent store file in the directory you found in the previous step.
Since you have existing apps, you probably want to move the existing data into the new app group directory. You'd do this by using migratePersistentStore:toURL:options:withType:error: to move the existing store to the new location from step 2.
At this point both apps can read and write the same directory. When people buy the paid app, the data is literally already there for it.
The keyword is Inter-App Communication. One straightforward way would be to write a URL scheme handler.
From: iPhone OS Programming Guide
Apps communicate only indirectly with other apps on a device. You can
use AirDrop to share files and data with other apps. You can also
define a custom URL scheme so that apps can send information to your
app using URLs.
Note: You can also send files between apps using a
UIDocumentInteractionController object or a document picker. For
information about adding support for a document interaction
controller, see Document Interaction Programming Topics for iOS. For
information about using a document picker to open files, see Document
Picker Programming Guide.
https://developer.apple.com/library/ios/documentation/iPhone/Conceptual/iPhoneOSProgrammingGuide/Inter-AppCommunication/Inter-AppCommunication.html
I've been researching literacy about the secure aspect of the NSUserDefaults leveraged by the ManagedAppConfig capability of iOS.
We are leveraging this "new" iOS capability to configure our enterprise application via various MDM systems used in our customers landscape.
A debate is now raging on how secure it is.
From our side, the only way that we have found to get this information is to actually JailBrake the device. Which of course would be detected by the MDM system.
Any other security vulnerability that we may have missed there ? Anybody looked into the security aspect of this feature ?
Thanks!
Ingrid.
Everything you store un NSUserDefault is easily accessible (with an app like iExplorer for mac, for example). No need to jailbreak. It is all stored in a .plist file in the Library/Preferences folder of your app.
I had to hide some information before, the way I did it was by using Data Encryption. For more information, read the section called Enabling Data Protection
All you would need to do after enabling correct data protection, is to create a file and store your configuration there. By putting the Data Encryption to NSFileProtectionComplete, your file will be visible, put not readable when the device is locked. For this to work, the user must have set a password on his device
Disclaimer: I am new to Windows Store App development.
My app is a Windows Store App (for desktop). The app has to create some content using user's input and the data can be considered as documents. Also, the document'd be in a proprietary format. The user should be able to see all those documents listed inside the app every time he launches it.
My question is where to save these document files. I have no issue it is directly accessible to users without using app (it is their data).
The document suggest roaming (limited storage) and local storage. But both are deleted once the app is deleted (bad for the user).
http://msdn.microsoft.com/en-us/library/windows/apps/hh464917.aspx
Document also states that accessing right for My Document folder is granted only if the developer is a company (bad for me).
http://msdn.microsoft.com/en-us/library/windows/apps/hh464936.aspx
Any other popular pattern from developers (apart from Azure, SkyDrive and any online storage)?
On app's first launch, you can allow the user to choose his/her folder as per choice, and then add that folder in future access list. So you can access that folder anytime. Please check below given links.
How can I save a StorageFile to use later?
Exploring WinRT: Storage.AccessCache
Windows.Storage.AccessCache Classes
I have encrypted files downloaded and available for offline view in a folder, I would like to know:
how to open them in the appropriate reader as these are ms office docs and prezi format
I suppose they will have to be unencrypted so that reader can read them but in this case how to ensure security?
which folder to use to avoid iCloud sync, I already read this Disable iCloud sync
Does iOS protects documents of the application by encryption based on app key as I read it or am I wrong?
Speaking extemporaneously, as thoughts occur, Sven is right about UIDocumentInteractionController and that objects are identified by URL.
However, it's possible you don't need to unencrypt your files on disk for this to work. You can probably write your own little URL protocol (subclass NSURLProtocol and implement methods appropriately; you should end up checking that URLs are within the invented scheme you've created — e.g. myApplicationEncrypted:// — then posting data packets to a NSURLProtocolClient) and register it with the device via NSURLProtocol +registerClass.
You'll obviously need to decrypt between disk and protocol client. So you'll be passing unencrypted data on — you'll need to make a trust judgment on UIDocumentInteractionController.
The document interaction controller is documented to work within your app, so there shouldn't be sandbox concerns.
You can send your documents to other apps using an UIDocumentInteractionController object. You initialize it with a file URL pointing to your document and then use one of it’s methods to present it.
This takes care of displaying a preview (if possible) and letting the user select the application the document should be opened in.
The document has to be decrypted for this to work. You then cannot make any guarantees about the security of your file - once it is handed over to another application it is out of your control.
If your app doesn’t explicitly opt-in to use iCloud sync your data will not be synced with iCloud. What will be sent to iCloud are backups of the whole device though (if enabled). There are ways to disable this for single files as you already read in the question you linked.
The iOS file protection is based on a device key, not on a per app key. This also is not necessary because apps are protected from each other by the sandbox, unless your phone is jailbroken. On a jailbroken phone there are no security guarantees.