As far as I know, NSURLCredentialStorage is just a wrapper for the keychain services with a more convenient API. Which is why I'd like to use it. But I also want to take advantage of the Data Protection feature kSecAttrAccessibleWhenUnlockedThisDeviceOnly that keychain offers.
Is there a way to set this attribute when using NSURLCredentialStorage to store credentials?
Turns out the answer is Yes, kind of. I looked into the keychain item that NSURLCredentialStorage created. It is of the class kSecClassInternetPassword and has the access key kSecAttrAccessible set to "ak", which is kSecAttrAccessibleWhenUnlocked. So the password is not decrypted while the device is locked.
The only downside is that NSURLCredentialStorage doesn't offer a way to change that to kSecAttrAccessibleWhenUnlockedThisDeviceOnly to get an additional level of security for your backed-up data. You could only change that attribute manually on the keychain item using the lower level keychain APIs (i.e. SecItemUpdate).
Related
I am currently using Cloud Firestore for my iOS app, which allows users to store their expenses to the database, but in order to secure privacy, is there any way I can make sure that I can't read the data that they are inputing into the database. While the queries and all still work, I or any admin isn't able to see what users have put into their database?
No such feature exists. Admin access through the console and the Admin SDK is able to read all collections and documents all the time.
As #Frank van Puffelen suggested:
Obfuscating the data through encryption, will prevent any unwanted eyes from viewing any information. This will add to your workload since you will need to perform the encryption and decryption at either end of the app (client and server).
I believe, you could take advantage of firebase's cloud code, to minimise the amount of code execution performed on the device, but I have never tried this, so am unable to confirm.
As far as an encryption key, you have a few options:
The user's password: This is one way of ensuring the encryption without revealing the key to any admin, since passwords in firebase are already obfuscated from any viewer. The only issue would be that a user would be locked into a password, as changing it would prevent decryption.
Store locally: You could store the key locally on the device, which would mean that the user could enter a key, or have one auto-generate, upon launching the app for the first time. You would then store this in the app's default key storage, and retrieve when required. Whilst, I believe this to be the safest, it means that your app could not be used across iCloud devices, since the key would be stored locally.
Finally, is CloudKit, which allows you to store data in the cloud. This is private, and only accessible to the user's cloud devices.
I realise that there is no code in this example, I am not currently at my desk, for which I am sorry for, if anyone else would like to edit with some code examples, I would be grateful.
I hope this helps.
I use the Dropbox Datastore in an app that uses both the iOS and JavaScript SDKs. Aside from the 10MB datastore limit, it works pretty well.
But nearly every support request I get makes me wish I could have access to the user's data for debugging. Being able to see exactly what the user sees helps me to find and fix bugs very quickly.
Is there any way for me to access a user's data without logging into their account? Can I maybe store their access token and gain access to just their Dropbox Datastore data?
This is one of the attractive things about Parse: you can see all user data. While there is a lot of wisdom in sharding user data across Dropbox user accounts, it makes app debugging crazy-hard.
Any ideas? What do you do to get around this?
Dropbox datastores, like files, are considered the user's private data, and as such there isn't a way for an arbitrary party to gain access to said data without some sort of authorization (e.g., access to the account, having the data explicitly shared with them, etc.) Likewise, even the developer of an API app that a user happens to be using doesn't automatically get access to the data.
That said, if, as the developer of the app, you want to troubleshoot using your user's data, the most straightforward method would probably be to get an access token for that app/user pair from the user. That would replicate their setup most accurately. (Unfortunately, the Sync/Datastore SDK doesn't make it easy to extract/insert arbitrary access tokens like that though. So, in that case, this would be a bit of work to build some flow to get an access token, e.g., a small web app, and then some work to read data directly from the API.)
Alternatively, you may want to make it possible for the user to share the datastore with your own account.
In any case, it's very important that the user not be misled or confused as to what is happening or what the developer is requesting. That means being clear with user with regards to what the developer is requesting and what will be done with the data. In addition, apps should provide privacy policies in general.
I'm developing an iPhone app that lets users upload photos to a Google App Engine backend written in Python.
Data is transferred between the device and server via HTTP POST and GET. What is the simplest, most secure way to ensure only iPhones with my app can get data? Also, I don't want the user to enter in credentials, it should be invisible to her.
I could embed a key in the device and send that with every request which the server would check against. But a malicious user could potentially decompile the app and obtain the key. Any suggestions?
With your requirement that the user not enter any form of password, your options are severely limited. As you note, any shared secret key in the app can be pulled out by someone via binary extraction etc. -- in effect, you can't stop a really dedicated cracker finding out the secret and then just submitting that to the server.
There are approaches that are not watertight, but which might make it harder for wholesale abuse of your service. One example might be to release updates for your app every month (or two weeks, or whatever) that contain a new shared secret. Then obviously your web service has to expect the new shared secret, as well as accepting the exising secret, for each time period.
If your data is very sensitive, you might want to stop eavesdropping by using HTTPS; but as Nick says, if you use HTTPS for anything except authentication, you have extra hoops to jump through at App submission time.
Whenever you have a key stored on a device or in software that is accessible by someone it is subject to attack. iOS's keychain is generally a helpful way to store things you want to secure. However, it is still subject to attack. As with all security you need come up with a model that is appropriate for your application.
Also note that there are encryption export restrictions that you should familiarize yourself with if you be intending to use encryption for more than authorization.
I have an iPhone application that requires the user to login(username, password).
I currently store the credentials of the last succesful login and fill the textfields the next time the user launches the app.
Alot of the times though the user may have more than one account and I now need to implement something to store login credentials for more accounts.
How would you suggest that I do that? I looked around but I couldn't find anything related to this.
NSUserDefaults or Storing into sqllite or Storing into a plist are on of the ways of storing persistent data. But they are not secure. I will recommend Key Chain Access for storing secure data.
This link provides a apple sample code which uses key chain Access
http://developer.apple.com/library/ios/#samplecode/GenericKeychain/Introduction/Intro.html#//apple_ref/doc/uid/DTS40007797-Intro-DontLinkElementID_2
But one disadvantage is you cant test this in simulator it works only on device i think.
You can also add multiple items to the keychain.
Look NSUserDefaults at the documentation.
Maybe this tuto can help you : http://icodeblog.com/2008/10/03/iphone-programming-tutorial-savingretrieving-data-using-nsuserdefaults/
Try with CoreData...
I am looking for some suggestions on how to secure access to a RESTful API which initially be used by an iPhone application, but will have other clients in the future. The data exposed by this API must be kept secure as it may contain health information. All access will be done over HTTPS.
I was thinking that I'd like to require pre-registration of the iphones at setup and then also some type of PIN/Password on each request. So, simply knowing the password without pre-registering the phone/client won't provide access. I was thinking about somehow tying it to the iPhone identifier if that is possible, but not sure it would provide any additional security. The iPhone identifier is just another piece of information and it may not even be that secret.
So, some requirements would be:
Use some type of pin-based solution on the iPhone, but want more security then a simple 4-6 digit pin can provide.
No passwords could be sent in the clear.
Not be subject to reply attacks
Having to pre-exchange some data between client and server when setting up client is OK.
I would think that, if the application contains medical records, you would want to have the user authenticate every time they use the application or, at least, have some way of pushing down a disable message that renders the app useless in the case where it is lost or stolen. The 4-6 character password (pin) would also concern me with respect to HIPAA, if it applies.
You might want to treat it as a standard web app from the server perspective and do session-based authentication and access with a session that times out, perhaps after a long period, and re-authentication on timeout.
You could use SSL with client authentication. If a device gets lost, you can remove the certificate on the server. There are some obstacles though:
It is not entirely clear if/how you can do client authenticated SSL on the iPhone Unfortunately, there is not much documentation about it. Have a look at Certificate, Key, and Trust Services Reference
You have to create a private key for every device
You also have to figure out a secure way to transfer the private key to the device