I know how to save login info in the default user preference. But how to save the log in info for several days until the app ask the user to login again?
You SHOULD NOT confidential data in user preferences, NEVER EVER EVER do this please. Apple can reject your app if this security issue is detected in app review.
Ok the better choice you have is to save those info in Keychain, the Keychain is a system secured database for this kind of usage (store confidential information).
There is some info about KeyChain
Also you can easy find some libs like SSKeychain or play with Generic Keychain example by Apple to make things more easier, because KeyChain requires low level api to access and store data.
The interesting here is, if you use Keychain to store username and password for example, the app is able to "remember" even uninstalled and installed back by user. So you better is don't worry about the time, just try to log in with these credentials when needed.
Have a good lucky!
Related
We have an enterprise iOS SDK that uses Keychain to store highly sensitive information. These information are not available to the client's app.
I've always thought that you need a key to fetch the associated value from the Keychain. But recently, I found out you can ask Keychain to return all the stored keys in Keychain (IMHO, this is a bad design).
Since the client's app can easily fetch all the Keychain elements, I'd really like to create a separate Keychain store for the SDK only. I've looked over SO questions but never found an answer.
TL;DR:
How to create a separate Keychain store in iOS?
You can't.
The security boundary for the KeyChain is the app (Or the KeyChain identifier across multiple apps from the same developer if you enable KeyChain sharing).
Once your framework is embedded in the client app, it is part of the client app. It doesn't have its own context or process space or anything to distinguish its code from the client code.
If code in your framework puts something in the KeyChain then, to iOS, it is the client app that has put something in the KeyChain, and there is no reason to keep a secret from itself.
Even if you could create a KeyChain just for your framework, presumably the code that puts the information in the KeyChain is in your framework, so an attacker could just decompile your framework to obtain the information.
Currently in the middle of a rather long-winded process of deciding upon the use of TouchID within an application being developed due, to security concerns, and wondered if anyone had any advice?
The idea from a product point of view is that a user can register with the application with a username/password (bog-standard flow in case of fall back for devices with no touch id) and then at a later date, if turned on via in-app preferences, use the TouchID system to 'login' to the application instead of typing a username/password again.
My concern is that this somehow means we have to store something on the device (retrievable upon successful touch) which can then authenticate the user and allow them access to the API (via JWT token, but probably doesn't matter).
This goes against almost everything I have ever read and been involved in with regards to mobile application development, which is storing anything sensitive on the client device is opening yourself up to an attack vector.
Yet - many applications already do this, so I am wondering what a typical process for enabling such a feature would be?
The app is sensitive by nature, has some personal information management which would be bad if leaked, if this makes a difference to the approach!
Thank you in advance
As you know many apps use keychain to save user login name and password, but is it really safe? especially on device jail break mode. So another solution is to use Outh2 protocol to save those confidential infomation on server side which needs many changes on both client and server side (for my app).
How do you guys handle this tough issue? Anyone who knows please share and thanks in advance.
Keychain:
It has two level encryption options
lock screen passcode as the encryption key
key generated by and stored on the device)
But when the device is jailbroken its not safe too.
oAuth:
Eventhough you store credentials in server you'll have to save the OAuth TOKEN in client side there is no place better than keychain to store it in client side.So now comes possibility of extracting the TOKEN on jailbroken device.
As far as I know in most apps they use one of these approaches.
If you need those data to be very very secure.
Suggestions:
Store OAuth token in server not in client
Store the Encrypted Credentials in Keychain and store the encryption key in server.This approach would be easy for you since you said adopting OAuth is hard for you.
Note:
There are some open source libraries available which detects if the device you run or app is cracked if so you can take action like deactivating TOKEN,deleting critical resources,locking app etc.
I'm working on an iPhone app that is logging into a webservice and it's been asked of me to get the account login management into the settings page (i.e. next to Twitter, Facebook and Vimeo). From what I've been reading about the accounts framework, it appears that only those few companies have that ability.
I currently have it set up and working asking for login info periodically and polling the webservice for validation, but we're trying to move toward supporting moderately offline use, which means we need to have some sort of account info managed on the phone itself.
Can I use the built-in account framework for our own login credentials or is that not something that's available to a regular dev and I'll have to look for another way to do it on my own? Is that something that the keychain would be better for?
Using the keychain to securely store the users credentials is a good idea to start.
If I am understanding your question about a "built-in account framework", I don't believe there is a local framework for account management on the device itself that I am aware of that would be useful in this circumstance.
I've had to build an app that needed to authenticate to a web service that also needed to have some offline access. I ended up recording the validated authentication date and time in the NSUserDefaults and would let the user use the app for a 48 hours period before they had to re-authenticate. Their data was queued locally and when they had online access again, I would re-authenticate and then sync the data. Not the most elegant solution but it fit the project.
I used AFNetworking (http://afnetworking.com) to track the changes in network access and used to blocks to respond to the changes.
I am building a backend for ios apps, that support login in different networks.
Once the user login in to the network the client tells the news to the backend, and this could offer a list of worlds that the user might play, or even delete old worlds.
One way to steal another person's world is by saying that you are his social network id.
To solve that with facebook, we force the client to send us the fb_token, a token provided from facebook to the client, that we use in the backend to ask facebook if that specific user is the one that he told us to be.
If apple doesn't provide a way to validate this I understand that if an iOS app wants to use game center, it is directly forcing the app developer to also use iCloud because apple can validate the user credentials.
Did apple provide any way to validate user credentials?
The client on iOS can retrieve info about the currently logged in player in GameCenter, which has nothing to do with iCloud.
If you want to use iCloud to authenticate, you might have a different player than the one you wanted.
I think the solution is for the client to retrieve the player info in GameCenter, and send it to your server in an encrypted fashion (say HTTPS), including a timestamp and possibly other dynamic information. This way you'll know that the user info is being sent from the client app itself and there is no man-in-the-middle. That's really the issue that you are struggling with: how to ensure that client-server communication is secure.