I have a service that connects to a database through a restful api with username and password. My question is what is the best way to store those credentials in my iOS app so that they cannot be seen by any attackers (gain access to our database)? Is storing the username and password in a private variable enough? Do i use the keychain? If i use the keychain how do I use it and is it possible for those users to gain access to that information?
Keychain is the best way to go if available. I use UICKeyChainStore for my own apps.
Its actually dead simple to use that API. Here is an example from their page:
UICKeyChainStore *keychain = [UICKeyChainStore keyChainStoreWithService:#"com.example.github-token"];
keychain[#"kishikawakatsumi"] = #"01234567-89ab-cdef-0123-456789abcdef";
Another option would be to store only the password hash in the NSUserDefaults. You can read about best practices for hashing here.
Related
We are exploring the Graph API to let users authenticate to our service via their MS account. However, to be able to encrypt user data properly, we need a 'secret' that we can use. Typically API's return an application specific key that is unique to the user/application that can be used for this purpose. However, I don't see anything that would be usable for that in GraphAPI.
Questions
Can anyone tell if getting such an application specific key is possible using the Graph API?
Otherwise, we will generate a secret ourselves, but want/need to store that securely in the user profile that we would be able to get after logging in. Any suggestion on how to do that?
Thanks!!
Regards,
Rick
This is not currently supported in Graph API. Being said that, you can file a user voice for this ask so that it could be considered for future implementations.
Try storing the secret securely in the Azure Key vault and you can retrieve it from there.
I want to implement a second security, because when the phone is jail broken the keychain is vulnerable and I don’t want my passwords to be secure only by the keychain. That’s why I want to encrypt the password by me before save the in the keychain.
The reason I want to encrypt it is because the server for login accepts a plain text password not hashed. I had the idea to have a rout for encrypting and when the user logins for first time, the password is send as a plain text and after that encrypted.
The encryption to happens on the backend and the backend can decrypt it. Is this a good idea, because when the user changes his/her password he/she needs to enter the old one as a plain text and I call the encryption rout on which I sends the password. It is responding me with an encrypted one of it and I am
comparing them. So in the keychain is only the encrypted one.
Is there a better way if it is where to store the key if I am encrypting the password on the device? If it is a static hard-coded field it is not OK. If it is in the keychain too, and on the server it is possible to have a different encryption key for every user. What is the best way to do it?
There is no good answer to this question, as the threat vector is too broad. You want to protect some secret information even if the device security is compromised (someone other that the user of the phone has jailbroken / hacked it). The best information about this can be found in the article Secret Management on iOS.
TL;DR: “Don’t (but if you must, obfuscation wouldn’t hurt).”
My use case is something like this.
I'm developing a rest api and single page web application.
But I don't want to store my user credentials (email, password) with me.
I want to store it in more secure place. From that place I need to verify credentials and issue tokens, as well as first time user register with the system that user's email ID should be verified and also If an user forgot his password there should be a way to reset it as well.
Finally in my node.js back-end I need to protect my routes from unauthorized accesses.
Do I can achieve all this things using a authentication service provider.
I go through the firebase docs and found It is little bit harder to implement my what I want using the firebase.
Is authentication services capable to provide reset password and email verification and store user credentials.
Or it just a token generator only?
If you are asking if Firebase Auth provides the ability to generate tokens for verified email/pass credentials it securely stores with email verification and password reset, the answer is yes. Learn more from their official documentation: https://firebase.google.com/docs/auth/web/password-auth
They also provide the ability to issue session cookies better suited for a Node.js server side managed sessions: https://firebase.google.com/docs/auth/admin/manage-cookies
You don't need to store the credentials. Firebase Auth will store them for you using industry best practices.
At the moment I'm storing both the username and password for communication with the server (through Alamofire) in the iOS keychain. However, every now and then the keychain returns nil when trying to retrieve these items. Therefore, storing the username and password in the keychain is not a reliable option. Is there a better way to communicate with the server? Maybe a session cookie or something?
Do you have freedom to modify the server-side code? If so, you could check out JSON Web Tokens: https://jwt.io/
If not, instead of the keychain we could use NSUserDefaults (https://developer.apple.com/library/mac/documentation/Cocoa/Reference/Foundation/Classes/NSUserDefaults_Class/). But remember that this is an interface to store user preferences, it is insecure to store passwords in it. That's why you should consider using tokens.
See this related question: NSUserDefaults or keychain is better to save username and password in iPhone app
Should access tokens for services like Twitter and Facebook be encrypted?
In particular, should tokens be stored on the the device's Keychain vs. UserDefaults? What are some possible security issues that could arise if a user's device is stolen/taken
This is what I have come up with so far.
Pros of Keychain:
Encrypted
Cons:
No way to clean up when user removed app
Pros of UserDefaults:
Kept inside the app.
Cons:
No encryption.
Your UserDefaults 'con' needs amending: no encryption by default. You can encrypt the content yourself using e.g. CommonCrypto, but it needs additional work over storing the plain text.
The point of an OAuth token is that someone who owns that token can use the relevant service without having to present credentials. Therefore, you should protect it like you would protect the password if you had to store that instead, as it has the same value.
If the user's device is stolen, then unless they have passcode-locked their device the thief has the capability to use your app as the user in either of the situations you describe. If you do not encrypt the access token, then they additionally have the capability to extract that and replay it from code under their control.