Re: Suggestions on best practices for idle timeouts

[Eric Lukens <eric.lukens () UNI EDU>]

Our auditors have forced the web apps to time out after a short amount of
time since we don't force the desired screensaver timeouts on all our
machines (classrooms for example) and do not prevent access from
personally-owned devices for many of the apps. They've also applied this to
most of the student-oriented systems as well--class registration and so
forth, which are obviously going to be accessed with personal devices. The
auditors see the timeout on their checklist and want to enforce it
universally and without exceptions.

Another thing to consider is the action the timeout actually does.
Typically from an audit standpoint, it needs to lock the session and
require authentication again, it does not need to log you off and destroy
the session on the server-side. However, more often than not the easy
implementation in a web application is to destroy the session and log off
the user. I've seen people lose hours worth of work because their session
was destroyed in the background while they were still creating content, or
because they entered data into a browser window that had been open for some
time and had timed-out. If possible, it would be much nicer if the
application accepted the submission into a sandbox for timed-out sessions,
and upon a re-authentication imported the data. This re-auth could already
show the username and only require the password--this concept is very
common with ecommerce sites now. Obviously not every application can
support this, and it requires more work, but it would be much nicer to the
end-users and improve workflow. Obviously there should also be some sort of
time-out for the server-side sessions, but those can be much, much longer.
I suppose the same end result could be accomplished by maintaining several
different sessions in the background.

On Thu, Oct 29, 2015 at 9:18 AM, Tim Doty <tdoty () mst edu> wrote:

> 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


-- 

Eric C. Lukens
IT Security Policy and Risk Assessment Analyst
ITS-Network Services
Curris Business Building 15
University of Northern Iowa
Cedar Falls, IA 50614-0121
319-273-7434http://www.uni.edu/elukens/

"Security is a process, not a product."  Bruce Schneier