User Experience Stack Exchange is a question and answer site for user experience researchers and experts. It only takes a minute to sign up.
Sign up to join this community
My company has created lots of computer software but one issue we have is with login timeouts.
Some developers want to make them shorter for security, while most users want it be infinite? Is there ever a justification to have no login timeout? How short is too short?
The length of the time out is partly dependent on the sensitivity of the data and security of the application.
For something like a banking site the time out needs to be quite short so that there is very little chance of someone getting access to the account if the user fails to log off.
For something like Facebook the time out can be longer - though even there I think there should be some time out as there is still sensitive information someone could get access to.
How short is too short? - if the user can't complete the most common actions within the time out then it's too short. For example, if you are reviewing your bank statement you need the data to be visible for a few minutes so you can mark off transactions etc. Any shorter and you'd have to refresh the page and could lose your place.
For your application you'll need to time common activities and make the time out a little longer than that.
The justification for login timeouts depends on the security level of your application and the how the users use the app. If your app handles financial/sensitive data, the login timeout should be short (logically), approx. 3-5 minutes.
If your app is a CMS, use a longer timeout. I would suggest approx. 45-60 minutes. This is to prevent content administrators from loosing content or content formatting if they are on the WYSIWYG editor screen for 30 minutes, which I frequently see.
In regards to justification for no timeout at all; I have one site that has a no login timeout. It is specifically for sales reps that always forget their passwords. This was a required feature by the client, not my normal best practice. Everyone has their specific needs and business objectives.
My strongest recommendation here is, know the audience. Make sure you understand what the users are doing and how long they are one a page on your site before setting up a login timeout.
In Web apps ( if you are referring to that) the timeout is reset everytime the server hears from you. this can lead to a user getting logged out even if he is using your site, reading, observing data, writing content etc. as long as he causes no new requests to be made.
Consider detecting user activity through mouse/keyboard/scroll events and triggering every x mins an ajax request to keep the timeout long. This will also enable you to set a shorter timeout, so that when the user finally leaves the computer, he is logged out fast. (if security is a concern)
None of the answers submitted so far have taken accessibility into account. If your company sells software to public authorities in the USA, the European Union and a few other parts of the world, the software needs to conform to certain specific accessibility standards.
In the European Union, the relevant standard is EN 301 549, created as a result of a mandate from the European Commission and published by ETSI. For web-based interfaces, EN 301 549 refers to the success criteria for levels A and AA in the Web Content Accessibility Guidelines. For non-web software, the standard defines requirements that essentially transfer applicable WCAG requirements to software (and adds a few other ones).
The relevant requirement for timeouts in WCAG 2.1 is Success Criterion 2.2.1 Timing Adjustable, which reads as follows:
For each time limit that is set by the content, at least one of the following is true:
- Turn off: The user is allowed to turn off the time limit before encountering it; or
- Adjust: The user is allowed to adjust the time limit before encountering it over a wide range that is at least ten times the length of the default setting; or
- Extend: The user is warned before time expires and given at least 20 seconds to extend the time limit with a simple action (for example, "press the space bar"), and the user is allowed to extend the time limit at least ten times; or
- Real-time Exception: The time limit is a required part of a real-time event (for example, an auction), and no alternative to the time limit is possible; or
- Essential Exception: The time limit is essential and extending it would invalidate the activity; or
- 20 Hour Exception: The time limit is longer than 20 hours.
See also the associated document Understanding Success Criterion 2.2.1: Timing Adjustable. This document also links to several techniques you can use depending on the scenario that applies to your software.
Consider also what you do when there is a request to the server after a timeout. Do not just reject the request or redirect the page. Maybe an in-page popup to allow you to log in again, but consider carefully the user story if their session does timeout.
If you handle the timeout process neatly, you can reduce your timeout, which is a positive for security. If you expect users to be spending a lot of time reading or filling out pages then keep the timeout longer.
So consider your users, and consider your timeout story.
Supposing that timing out a web session is a solution to stop the unauthorized access to a computer and its data when the user is not present. Then the best solution is a system/local time-out; centralized in case of corporation.
IMO Web timeout should be just complementary to the previous security solution, so having only a short timeout period only when the page is accessed from non-corporation devices and the data is critical.
And if the web timeout has to be restrictive then detect the user event in current page as it was said in a post above; through mouse/keyboard/scroll events; AJAX,...
