I am making an IPhone app in which
userid and password is required in
all the screens to make requests to
the server, and I am thinking of
saving those 2 values in
NSUserDefault instead of passing an
object around.
I am also thinking it will be useful if user has logged in once,
and use the app again then user
don't have to enter his/her details
again.
But I am curious if it will be safe/good practice to use for first requirement?
I don't have anything against save these data on the user defaults. What I don't get is the idea to expose the user credentials on each request.
I would suggest you to ask for the credentials once, authenticate with your server and return a "session token". save this token and use it to validate the user on each request. (it means that you will save the token on you server or you will check the token using an algorithm)
Doing this you don't expose the user credentials all the time, you have control over the session, and you can expire it when you want, forcing the user to logging again.
For more complex implementations, you could Google for OAuth or XAuth and some related methods of authentication.
Cheers,
vfn
It's reasonable to save global values in NSUserDefault that you want to survive your app being killed and restarted (as can happen under iOS4.0).
Passwords should be saved in memory (maybe a singleton model object), or in the keychain, as various iTunes backup databases might expose stuff stored in user defaults.
Related
I'm looking at developing an application using the Yodlee FinApp API.
Their REST protocol requires you to login your users to their system to retrieve data. To do that, you need to send a login and password. A successful request returns you a token that is valid for 30 minutes. Before that 30 minutes elapses, you must log the user in again in order to retrieve a new token. Here's where the problem lies, in my opinion.
I could set something up wherein every time a user logs into my application, I immediately send their login info and password to Yodlee and log them in there as well. Then, I wouldn't need to store their password in my database in plain text. But what happens when 30 minutes elapses? I don't actually "know" their password, so I'm unable to get them a new token and would require them to log in again. It would be a real pain to have users constantly having to log back in every 30 minutes.
Alternatively, I could generate my own password for them when they sign up with my app and use that for my application's interaction with Yodlee. But then I have their Yodlee password stored in my database in plain text. Assuming somebody was able to gain access to my server, they'd have my application's credentials and also all user credentials, so they'd be able to mimic my application's process for logging in and gain access to user transactions. This seems like a bad idea.
What's the correct approach here? It seems like both of the avenues I'm investigating have serious downsides, but maybe I'm missing another option?
#aardvarkk- How are you planning to authenticate the user on your application?
If I understand correctly then you should be storing the user credentials in your application to validate the user and also to check if he/she is a new user or not.
When you would be having this data, you can use the same to login again on behalf of user before 30th minute & only when user will still be in session not every 30 mins.
And we would suggest you to not to store any of the user's credentials in plain texts. You could encrypt it before storing and decrypt before sending it to Yodlee.
Also, the access to your application credentials for Yodlee's production environment is IP restricted and hence only request's coming from your static IP can connect successfully to Yodlee.
[UPDATED]
For this Case:
You can call touchConversationCredentials API which extends the relative (or inactivity) timeout validity of the conversationcredentials i.e. UserSessionToken. You need to pass userSessionToken in this. And you can call this before 29th min of user session to extend his/her session for another 30 mins. But there's an absolute timeout of 120 mins, so after 120 mins of initial session creation it will expire.
First off, really try to avoid storing the user's password in plain text. That is just asking for a world of pain if anything goes wrong (e.g., if you get hacked) and can open you up to all sorts of legal trouble. Truly, don't go that way.
It would in fact be better off if you never learn their Yodlee credentials at all; you don't want to be them, you just want to interact with the system on their behalf.
REST doesn't really say that much about how systems authenticate to one another; many possibilities are available in general. All you can do is try to connect with whatever credentials you have, and if that fails, bail to the user (well, to client-side code) so that they can give you another token. REST does clearly state how a failure to authenticate should be conveyed, a 401 HTTP response, but that's all really.
We are currently planning a facebook client for a custom embedded system where it is very time consuming for the user (because of the few available controls/buttons and no touchscreen) to enter his/her account details.
Ideally the user would only need to enter the details once and then they get stored and retreived from there until the user deletes them (or changes password). I've read up a bit on OAuth and the access tokens but as far as my understanding goes, the only way to achieve "configure once" functionality is by actually storing the username and password combination since the access tokens will expire (with the offline token being deprecated this year). Am I correct?
We'd rather not store the user details locally in our device because of security concerns but it seems like we have no choice?
Best Regards,
Ingmar
Normally you don´t need to store anything, as facebook handles everything. Only if you have to store user-specific additional data (or settings), you usually just store the Facebook ID only.
I am building an iOS application and the user authenticates with my web service. I don't want them to login every time the app launches (the token lasts a month). So I'd like to cache this on the device somewhere.
What's the best way to do this, securely?
Can I just rely on the app remaining suspended and keeping the token in 'memory'?
2 options
Make use of NSUserdefault(store as access token or textfield inputs[Remember me option])
Keychain access(recommended) for doing the job.
NSUserdefaults is not secure for storing such credible values which is for authentication purpose.Keychain on the other hand is made to do this,safe and secure.
You can't rely that iOS will keep your application forever in the memory. So, you have to save the token to persistent storage at some point.
Look at Keychain Service for iOS. This is the best place to store things like passwords, tokens and other keys.
You can't do it "securely." A token is public knowledge, and as soon as its on your device a hacker could gain access to it no matter what you try to do to protect it. Putting it in the keychain won't change this fact. Even if you store it there, which would make it secure while it's in there, they can simply wait until it expires then snag the next one when it comes in over the wire next time. Your access tokens aren't the thing you need to worry about securing, because you can't, in fact, do that in a mobile environment.
What this means is that you can store it anywhere you'd like. NSUserDefaults is fine, the keychain is fine, a database is fine, a text file in your documents directory is fine. All of them are equally secure because a determined hacker can simply wait for the right opportunity to access the data they want. You should instead worry about securing your users' authentication credentials. Make sure you store those in the keychain, and only ever communicate with your API over HTTPS to a server with a valid SSL certificate.
I'm creating an iphone app where the user logins once (when they open the app for the first time), then will never have to login again (like how instagram does it). The app will automatically log them in the next time they open it up. However, the app makes a bunch of requests to a web server.
What is the best way for the server to issue session tokens? How long should the session tokens be valid for? How can I ensure the user never has to log in again, while still providing secure session tokens.
One approach is for the server to issue a token to the user when the user logs in for the first time, and make that token permanent. That, however, does not seem secure.
Thanks for the help!
Well, generally the session is already handled through session cookies. Unless you're planning to have third parties connect to your service, I think it's a bit overkill to do anything besides basic http authentication. I would definitely send all of your connection requests over an https connection though.
As far as persisting the session on the iPhone side, you can save the user and password in the Keychain, and then automatically retrieve and send it to the server when it requires you to log in again, without having to prompt the user to log in again. How often you want the sessions to last on the server end is really up to you.
What is the best way for the server to issue session tokens?
One way to do it is using OAuth. It is more complex than cookies but it has more features.
A token is granted to each application and can be revoked by the user from a page in the server. This token can be permanent or temporary. You can store it as plain text or inside the iPhone keychain, depending on the level of security you need. There is open free code for server and client implementations. Another benefit is that clients can log in your service using their Twitter/Facebook/... account so they don't need to register on your site.
I'm building an app that performs similar functionality that one website does: register, login, submit order, view orders and etc. Now, do I have to do anything explicitly in order to get things working?
After successful login, a webserver establishes a session and sesssion ID and related session info is written to related cookie. IMHO, I just need to call webservice with login credentials and then the rest will be done implicitly. After successful login, every requested user page from user area will be checked with sent cookies and session file at server side. So, do I have to do anything else in order to get into secure area?
Agree with what #sicKo has said. Remember, sending data over wireless network is not secure. Do be careful on the transactions when money and authentication involved.
In addition to what #sicKo has said, you may now consider the coming iOS5, store the value at iCloud.
You just have to send the value to verify the user to the webserver.. and u can keep the session alive in iPhone using NSuserdefault..
U might want to encrypt the sensitive data send over the network such as username and password.