Educause Security Discussion mailing list archives
Re: Suggestions on best practices for idle timeouts
From: Brad Judy <brad.judy () CU EDU>
Date: Thu, 29 Oct 2015 14:27:08 +0000
While I agree that endpoint security is important, keep in mind that we are talking about applications where the user base might be primarily students, prospective students or otherwise from endpoints under no control or influence of the organization. SSO configurations often complicate idle time-outs and log-out scenario because multiple sessions exist and a time-out or log-out might impact only one of those sessions. Simply mapping out and explaining the time-out and log-out paths in a multi-application SSO environment can be a non-trivial task, let alone expecting most folks to understand or remember how it works in any given application. Personally, I think timeouts are perhaps more important these days than in the past. Modern devices might rarely, if ever, see the web browser actually closed to clear out any temporary cookies/tokens/sessions. On Android or iOS devices, the browsers are typically only restarted when someone restarts the device itself - most users don’t' get into killing individual applications. Brad Judy Director of Information Security University Information Systems University of Colorado 1800 Grant Street, Suite 300 Denver, CO 80203 Office: (303) 860-4293 Fax: (303) 860-4302 www.cu.edu -----Original Message----- From: The EDUCAUSE Security Constituent Group Listserv [mailto:SECURITY () LISTSERV EDUCAUSE EDU] On Behalf Of Tim Doty Sent: Thursday, October 29, 2015 8:18 AM To: SECURITY () LISTSERV EDUCAUSE EDU Subject: Re: [SECURITY] Suggestions on best practices for idle timeouts * PGP - S/MIME Signed by an unverified key: 10/29/2015 at 8:18:14 AM On 10/28/2015 12:43 PM, Emily Harris wrote:
We are in very lively discussions about best practices for idle machine timeouts. Most of the discussion is around timeouts for faculty machines, as they could set up a computer with a video or movie and not touch the machine again for 2 hours. We are specifically talking about timeouts for Single Sign On applications.
Since you say "Single Sign On application" I am assuming you are talking about timing out web sessions. If not, ignore this. Summary: Timing out web sessions is a workaround for not having local time outs. If possible, local timeouts should be used as they are more effective. If web session time outs prove necessary then the idle time can be shortened by using pop ups. Longer version: I don't know that it is popular, but my opinion is that timing out sessions is over-rated. As far as I can tell, the justification is that the user may walk away from their workstation, leaving it unattended, and some other individual will then abuse it for the logged in access. The problem in this scenario is not timing out web-based sessions, but the lack of end point security. Web sessions are far from the only access that is granted by an unsecured terminal. Consequently the best solutions will revolve around improving end point security. For example, mandating a screen locker with an appropriate idle time. This has the advantage that a user's sessions don't time out just because they are watching a training video. Another thing that can be done is to educate users about "Windows-L" and encourage them to hit those keys whenever stepping away from the machine. In shared office space encourage users to still secure their workstations, but accept group monitoring where at least one person is able to prevent unmonitored access by visitors (this is naturally not as good and works best when the users all have equivalent access -- still, it can be better than nothing). Pain associated with frequently typing in passwords may be alleviated by using proximity lock/unlock. My experience with this has not been good, but that was just kludge involving cell phones and blue tooth. But in the end, you are more likely to be able to negotiate a shorter idle time when using local timeouts (which can be cognizant of user activity, such as video watching) rather than timing out web sessions. And if the time out is shorter then that is addressing the need better, right? Another thing to keep in mind is that environments vary significantly. My idle timeout is only somewhere around five to fifteen minutes, but that's because 1) I have my own office, 2) I always lock the screen when I get up, 3) and I always close and lock my door. In contrast, we have a security conscious employee who works in an open, shared space who voluntarily set the local idle timeout to one minute (and still uses Windows-L when they get up). I'd be surprised if you were able to customize web session timeouts in such a fashion so a one-size-fits-all model is used which means insufficient timeouts, excessive aggravation, or both. When the concern is about end points over which there is no control (e.g., student-owned systems) then having an idle-timeout for web sessions can make sense. The biggest risk there is that there is no way to actually measure user idleness. Its very frustrating for a user to spend an hour typing into a form only to discover that the server idle-killed the session -- and some web applications are designed so that you can't go back to reclaim the text (or it just isn't that simple if there are a lot of fields). If feasible, a "prove your still there" pop up can be a reasonable work around and permits shortening the idle timeout. Tim Doty * Timothy Thomas Warren Doty <tdoty () mst edu> * Issuer: Internet2 - Unverified
Current thread:
- Suggestions on best practices for idle timeouts Emily Harris (Oct 28)
- Re: Suggestions on best practices for idle timeouts Frank Barton (Oct 29)
- Re: Suggestions on best practices for idle timeouts Tim Doty (Oct 29)
- Re: Suggestions on best practices for idle timeouts Brad Judy (Oct 29)
- Re: Suggestions on best practices for idle timeouts Tim Doty (Oct 29)
- Re: Suggestions on best practices for idle timeouts Eric Lukens (Oct 29)
- Re: Suggestions on best practices for idle timeouts Velislav K Pavlov (Oct 29)
- Re: Suggestions on best practices for idle timeouts Brad Judy (Oct 29)