Re: Suggestions on best practices for idle timeouts

[Brad Judy <brad.judy () CU EDU>]

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