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.
Related
Anyone used epicshaggy / capacitor-native-biometric plugin and have been able to make it work. I have just been able to trigger the NativeBiometric.verifyIdentity( function and make it recognize my biometrics, but that's about it.
I've crawled the internet and haven't found a complete example of how to use it. To summarize, i just want to understand how can i use biometrics to login a user. How do i make my server uniquely identify a user and provides login token.
According to the CapacitorJs docs, and epicshaggy/capacitor-native-biometric, the correct way to work with user credentials is with the provided methods:
NativeBiometric.setCredentials()
NativeBiometric.getCredentials()
NativeBiometric.deleteCredentials()
These methods
Securely stores user's credentials in Keychain (iOS) or encypts them using Keystore (Android)
These methods are also only available on native devices, hence "method not implemented" when attempting to run in a browser, and must be behind Capacitor.isNativePlatform().
Providing an updated answer because this is still a top result when trying to implement biometrics with CapacitorJs
did you found any solution to this so far? I think your own problem is how to recognize a user? there is actually how I used to do this in react native. First of. you need to have some kind of extra "local storage key" that stored values or user credentials when they log in through the inputs. keep in mind that you are not clearing the "key" even if the user "log out" of the app. so in that case. before they could be able to use biometrics users need to sign in the proper way with the inputs so you could save their credentials like email or any unique values or whatever to use later.
Now, my problem is all the functions are not even working for me ah. it keeps saying "method not implemented"
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.
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.
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...