Or put another way - is there a process for deciding how long a user's authenticated session should last?
Add a comment
|
3 Answers
I don't agree with Edgarator that you should ask the user, especially not at log in.
It is all very nice and well to allow the user to change it, but don't ask them to make a decision that is totally unrelated to what they want to achieve with your application.
Decide a sensible default for yourself - possibly using the criteria Edgarator shows in his answer. Make it short-ish. And DO provide option to change it longer in some settings dialog.
answered Sep 18, 2012 at 12:14
-
+1 agree: at login time it is completely useless. I personaly like my eBanking client: shows countdown from 20 minutes in upper right corner to session expiration. with button to start over. and any operation resets the counter too. the point is: user knows on every page how long will session last and he has no option to change predefined amount. but it is determined by sensitivity - eBanking. for other purposes it may be few hours or days... Sep 18, 2012 at 15:18
-
I don't think you read well my answer, but I appreciate the comment. I'm suggesting to the OP to learn about his/her audience by running a test and tracking, giving that there are thousands of different scenarios, and providing a set of questions to start off. Sep 18, 2012 at 16:23
-
@edgarator: I read it well enough, and I agree with testing, and your comments regarding sensitivity of data being a factor in the length to be chosen. I just strongly object to asking the user to decide, especially in the login screen as shown in your mock up. Sep 18, 2012 at 18:09
It would be difficult to find a standard time to measure how often to expire a session in a mobile device.
So, what I would do is:
- Define what's my user
- How sensitive the information I'm dealing with is
1. To define the user
You might want to think around the lines of:
- Is he security conscious?
- Does he need quick and easy access to the application? (perhaps older people would get annoyed by having to type a password with symbols, uppercase and lowercase with at least 8 characters every time).
- Would making it difficult to login a burden for adoption or my application would be needed regardles of how difficult is to log in?
If this doesn't matter perhaps you could add different session expiry settings at the beginning and learn (by tracking it on your server) from your user how often your standard user like the session to be expired. For example:
download bmml source – Wireframes created with Balsamiq Mockups
2. To define how sensitive the information is:
Pretty much all legal implications here:
- Think about what would happen if your information gets lost?
- Should I take care of my user (beyond providing the means for a secure connection), or
- Should I let the user deal with the consequences of device mishandling?
- Mobile Applications such as Facebook don't care much about expiring the session on mobile devices due to the fact that it would stop people from using it A LOT.
- Mobile Applications like GMail would expire the session every once in a while, so that you don't get annoyed by it if it happens every blue moon, but still if someone breaks into your phone, they wont have unlimited access to do eavesdropping on your phone.
- Mobile Applications such as Online Banks would expire the session after closing the application, as unwanted transactions could be made, and that could affect the bank itself. Also, on this, a security aware user is most likely to start saying that the app is no good due to the fact that it lack security.
-
I think the question was "how long", not "how" to keep session. I am interested too. Sep 18, 2012 at 7:39
-
Thanks @FrantisekKossuth, I think I'll rephrase it. What I was trying to say is that Facebook has unlimited session time on its mobile application, Google will expire the session after two weeks and a Bank will expire it immediately. As it depends entirely on who own the data and what potential impact it has if the data gets stolen. What I was trying to imply with my answer is that there's no single answer to this question as it's dependent on the audience and the information being handled. So the question is to broad to answer. Sep 18, 2012 at 7:52
-
Don't ask the user at login. Decide for yourself. Make it short-ish. Provide option to make it longer in some settings dialog. Sep 18, 2012 at 8:37
-
1Thanks for your comprehensive response, @edgarator. I agree there isn't any standard for this, but it appears that the main factor is sensitivity of data available in the app. About Facebook, my guess is that it prioritizes engagement over security. Sep 18, 2012 at 10:38
-
@MarjanVenema I think providing options with a sensible default (validated over time) is the broadest solution. You should add that as an answer. Sep 18, 2012 at 10:39
Once. A User should be asked to login to a mobile application on their own personal device one time per device/install so as to access data pertaining to their own account. Anything more is implying that their mobile device is not personal and/or the communication channel is insecure (e.g. MITM attacks).
Though there is room for considering (worrying about and putting controls in place to mitigate the risk of):
- rooted devices (whether intentionally or via a vulnerability),
- stolen devices,
- sharing of the mobile phone.
For those cases, other controls exist and they may be sufficient and/or better implemented than controls in your own app. E.g. lockscreen, remote phone wipe, etc for a stolen device. Family controls for sharing devices. And for rooted devices, well the breach of personal or sensitive data in your app/system is probably minor in terms of what can be done across the device in that scenario.
So ultimately it should come down to a risk assessment of your system, the data it works with, the actions it can make, and a decision-maker's willingness to sign off on identified risks.
