I have a big database with devices token.
I guess a lot of my base are obsolete token.
How can I detect if a device token is obsolete?
Thank you.
For this exact reason, Apple provides a feed back service. You should set up a batch process or stored procedure in your database which periodically fetches invalid tokens and removes or mark as inactive in the database.
APNS : Feedback Service
Related
My App only allows user to login on one device at a time. And I would like to use JWT.
Is it possible to invalidate the other JWT on devices other than the one I'm on? without storing extra information in DB / cache (e.g. storing active user's JWT).
After weeks of investigation and trying, I confirm there is no way to invalidate the other JWT without DB. the final solution is to store every JWT in DB (Redis). When validating JWT, not just check the token itself, also check if it exists in the DB
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.
For example: if I am retrieving User.Identity.Name, does it come from .ASPXAUTH cookie or is retrieved from the database using my membership provider?
Are any database requests made when I access User.Identity?
Thanks.
EDIT: Right now I am pretty sure it comes from an authentication ticket cookie, but can't find any official documentation to confirm this. Anyone?
This should answer your question...
"The forms authentication ticket not only includes the user's identity, but also contains information to help ensure the integrity and security of the token." Excerpted from the following Microsoft article:
http://www.asp.net/security/tutorials/forms-authentication-configuration-and-advanced-topics-vb
In addition to that explanation, observing ASP.NET behavior also supports the conclusion that the username is, in fact, stored in the ASPXAUTH cookie: ASP.NET does NOT hit the database on subsequent page requests after the user has been authenticated. You can prove this yourself, just as I did, by running SQL Profiler to monitor the database as it is used by an ASP.NET application.
Also know that username and authentication ticket data are NOT stored in session state. Aside from raising security concerns, that kind of implementation would cause ASP.NET Membership to break when session state is disabled. Here is another Stack Overflow answer indicating that Forms Authentication (Membership) data and Session State have nothing to do with one another:
Does FormsAuthentication.SetAuthCookie() make a session based cookie?
That answer also links to an MSDN article, here, that explains the ASPXAUTH cookie in detail, though the article I referenced above seems to be more current.
I believe the authentication information are specific to a session and maintained within the ASP.net process or outside or even SQL server. Once a user is authenticated a session token is generated, the token is used to track information of the authenticated user in the state service. On subsequent requests, the session token is used to retrieve user identity and thats where we get pre-populated objects like User.Identity.Name. this must be implmented either in Forms Authentication module or windows authentication module depending on the type of authentication one is using. If you set to cookieless authentication mode, the session token is displayed within the URL. Once the session expires, all the information pertaining to the session is removed from the state service.
Hope this makes it clear!
It depends on the type of Session you are using. Sessions can be varied by using two parameters
1. Use of Cookies-Cookieless, Or use cookie
2. Process to store the session state information -Inproc (in process), outproc (ASP.net state service), or Sql Server.
If you use Sql Server to store the state information, a data base query will certainly be made to fetch the session data.
More details here-
http://www.codeproject.com/KB/aspnet/ExploringSession.aspx
.ASPXAUTH cookie / User.Identity comes from authentication (Windows, Forms).
If you are trying to get the user for Membership you need to use
Membership.GetUser()
or
Membership.GetUser(User.Identity.Name )
documentation here which would result in a DB call.