How to store user Login details(user, pass) for multiple accounts on iPhone app - iphone

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...

Related

How to prevent a user from changing the app code in order to write data to Firestore?

In my app users can read and write data on Firestore.
In the Firestore Database there Is also a "Credit" document for each user where the balance of coins Is stored.
How can I be sure that no One could modify an APK of the app in order to change the balance?
In the app there are some functions that remove some coins from the balance, my fear Is that someone could change the code and add coins instead.
assuming that your app implements firebase authentication to authenticate operations on firestore it's safe to say that your app is compiled with a key and it has an hash.. it's not possible to someone to decompile the app, change the code and recompile it with your key.. so the new "hacked" app will have a different key and hash and firebase authentication will not work and your db will be safe
I think you need to secure the data itself. In your scenario I don't think you can have code in the app that simply writes a value to the balance. You need to create a separate API or firebase function to secure what you are trying to do.
If you want to ensure that only your application code can call Firestore, consider enabling Firebase App Check.
Just keep in mind that:
Using App Check does not guarantee the elimination of all abuse
So you'll want to combine it with other security measures, for example through the server-side security rules that Firebase also offers for Firestore.
Also see:
Locking down Firebase DB access to specific apps
How to allow only my app to access firebase without a login?

Read Firebase rules without authentification

I found a previous question very similar to mine, however the other developper needed to write to Firebase and I don’t, hence this near duplicate question:
I have a very simple database with about 150 documents and the users don’t need to authenticate to use my app. Authentication just don’t make sense for what the app does and users only read the database, they don’t write.
My current rules are read allow only which of course triggers the Firebase rule warning daily.
1) Is there a way to set rules similar to “only requests coming from my app can access it”. Given that the app is linked to firebase one would think it’s possible?
2) If I must use authentification, is there a way that I can do this behind the scenes so that the user is unaware of that? Maybe by using a UUID to identify a user and no password or something like that. I want to avoid showing a log in screen at all cost. Think of it as asking to log in to check gas prices...
** This is an iOS app
No, it's not possible.
You can use anonymous authentication to create a user account without requiring a sign-in.

How to restrict read access by admins on firebase firestore database?

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.

One time login in iOS - Most Efficient Way?

I am looking for the best way to do a One Time Login for my iPhone application. Using iOS 5.1.1 SDK but targeting iOS 4.1 for deployment.
Its purpose is to fetch a generated ID: if an ID exists then I don't need to login anymore, the ID will be returned in XML.
My application is an extension to a current web based service, it involves asynchronous HTTP POSTs on location updates with an ID as an identifier and checking the XML returned for any errors. The ID does not expire. It is a single view application as it just requires a start/stop button.
The username for the web service never changes so I just want to fetch the ID once off, there is no benefit or security risk if a person was to hack things and get the id due to the nature of the service and the application providing no information on the user. The process I would like goes as follows.
Application launched.
Do we have an ID stored? (yes/no)
If yes go into application.
If no present username/password screen to get ID.
On entering username/password, password is encrypted, sent to the server for verification, if yes then an id is returned and stored.
The username/password would be two inputs and a login button.
What would be the best way to go about this? I really don’t know what direction to follow here.
What I would recommend doing is using iOS's Keychain to store the ID of the user. You can never be too safe, Example usage can be found here GenericKeychain alternatively theres numerous easy to use wrappers to accomplish this.
If you really dont care for security, NSUserDefaults works for storage.
Also, I would suggest utilizing iCloud Document storage to make this ID persistent for all the user(s) devices. You can refer to this thread for more info.
Hope all that I suggested helped with your question !
UPDATE: For anyone else who finds this answer useful. As #sandmanza mentioned, be sure to include the Security.framework, if you go the Keychain route.
You can save ID in NSUserDefault and upon launching the app, you can retrieve ID from NSUserDefault and check whether ID is present or not, and based on that you can proceed further.

How do you keep a user persistently logged in on an iPhone app?

On my iPhone Facebook app I think I've only logged into it once.
On my Mint financial app, I've logged in once. whenever I load it back up, I give a four digit PIN number which was setup in the app, and I never have to log in again.
I'm building an application right now where this type of behavior would be highly beneficial.
Do they just set an auth cookie of some sort and just set it to expire way into the future? Or is there another way of handling this?
Thanks!
You can use the iOS KeyChain to securely store credentials as well. This can be simplified by using this code found on github ( https://github.com/ldandersen/scifihifi-iphone/tree/master/security/ ) , with some basic instructions found at http://gorgando.com/blog/tag/sfhfkeychainutils
That depends on the context of your application. If you authenticate against another API, the supplier of the API usually provides you with some sort of authentication key which might expire after a certain time. You would store this key in your application once the user performs the authentication step and reuse it for every request.
Basically, the data you have to store and the time before your user has to re-authenticate (if ever) depends on the supplier of the API you're using.
I can't speak for Facebook or Mint, but the simplest approach is to use a cookie / token and store it in NSUserDefaults.
When the application is launched, see if token is still valid. If not valid, force the user to sign in again.
I am taking a stab in the dark here, but:
I am assuming the login information is encrypted and then stored on the device somewhere. Upon creating a new instance of the app this data is sent to the site for all of the oauth/login/etc stuff. Once this is done the Facebook app stays on until: 1) the device is turned off, or 2) you manually quit the application.
Maybe this will start to help you, but I am sure better answers will come.