Your Session Has Timed Out

@Jeff - “Isn’t “you’ve been idle too long, lock the workstation” the job of the operating system and not the job of every little application that I run to implement in their own peculiar oddball way?”

In a perfect world this would be the case. However if a user is filling out a form and walks away without locking the PC, will that user blame the OS or the site for any loss of personal information? Granted if the form is still up anyone walking by can take info out of the form, but if the session has been expired the intruder cannot cancel (submit or close) that page to pull other personal info from other pages (say personal data, shipping address, payment info).

I use a hidden iframe with link to this content:

html
head
meta http-equiv=“refresh” content=“240”
/head
body
/body
/html

It works perfectly.

html
head
meta http-equiv=“refresh” content=“240”
/head
body
/body
/html

That was the content

It should be made difficult, and not the default, to keep you logged into a banking site.

But if you tell the site that you’re sitting at your home computer, the damned site should remember it.

Just because I only visit my credit card site once or twice a month, I’m always having to jump through stupid hoops like getting an “activation code” to log in…as though someone else is going to log in and pay my bill for me otherwise.

Another solution is to avoid sessions as much as possible, ie design RESTful-ly.

Sessions work against the underlying technology, and working against any technology always creates problems.

I think session timeouts are helpful for web applications. How many times have you walked to a public computer and found that the previous user didn’t sign out? As someone said, this could be a serious problem for financial web applications.

What we’ve done on the apps I worked on is popup a warning about session expiration (say 15 minutes before it expires). The warning dialog contains a button that the user can click to extend his session.

Session timeout problem for Corporate Apps.
This can’t necessarily be done on the internet though. Here are some solutions:

  1. HTTPS all the way for secure apps!
  2. Keep user logged-in. (remember me via cookie, ip, etc.)
  3. Store current view state (page id and field contents) in a cookie! (time based, as you type, etc.); encrypt the cookie!
  4. Support concurrent access over the same session.
  5. Support bookmarkable pages.
  6. 8 hours (work shift) timeout.
  7. Flash / Applets for state management.
  8. I’m sure there’s more!

Wouldn’t another option that would be secure (requires authentication after session expiration) but saves the form data be a better solution?

Has anyone tried the following:
Using Session.IsNewSession you can test if a session has expired, then serialize the form data and location of the current page. After login, redirect the user back to the current page, already populated.

Instead of ‘kicking’ the user, why couldn’t the site simply have the user reenter their password if they’re away for more than x minutes, so as to revalidate and confirm their identity? I’ve had way too many situations where I simply can’t find the content I was viewing again after getting booted by a site, and it’s rather annoying…

If I’m writing a banking application, no way am I going to trust the client to handle session timeouts for me. The OS might have the screensaver/lock-workstation functionality switched off, the browser may not clear cookies when closed down, any number of things could prevent this from working.

As a user, I’d far rather have to login again after walking away for an hour than run the risk of the next person to use a public workstation opening the browser to find themselves authenticated on my bank’s website.

And seriously, do that many people wander off for an hour in the middle of filling in a form? I reckon I’ve done that maybe twice in 15 years of using the web. Are attention spans really that short these days?

what is the point of a captcha when the captcha doesn’t change?

Do you want to be the most easily spammable site with a “captcha”?

I agree with Benedict. It is possible to create great websites without relying on some in-memory session state on the server. By using a RESTful style of architecture you are playing the web the way it was meant to be. As a plus you get a much more scalable application too!

I still use a cookie to store an encrypted user token. But this can be updated with each request-response to prevent replay attacks.

“Imagine if Microsoft Word or Excel “logged me out” if I was idle too long in a document.”

Word doesn’t log you out, but it has a terrible habit of auto-saving - which is almost as bad. I can’t turn that setting off at work, and it drives me mental. I have to work with a lot of other people’s documents, and in order to get them to print I often have to make changes - but the people I’m printing for like to have their documents left in peace. If I make a change and don’t “log out” fast enough, then it makes those changes permanent! What a topsy-turvy world we live in…

Jeff,

You seem to neglect two use-cases:

  1. The cybercaf
    I go in, type some e-mails, surf the web, … But somehow my time expires and the screen is locked. Countless cybercafs don’t bother rebooting the machine or killing all apps before the next user logs in, hence he will have access to all my stuff.

  2. Online banking and other highly sensitive websites
    Do you really want this stuff to be accessaible to anyone in case you go for a coffee and forget to log your workstation. Or worse, in the cybercaf as described above.
    Plus, I do believe in these rare cases it gives the user an additional sense of security. Don’t forget that these services are also being used by large masses who now just starting to put their trust in something other than the agent they’ve known at the counter for the last 20 years.

So here is my suggestion:

  • For all PCs where the “remember me” feature is activated, assume it is located in a trusted environment and enable to anti-timeout feature.

  • For all other cases, assume it is a public and/or untrusted environment and expire as usual.

Cheers,
Axel

P.S.: This ties in very nicely with “auto-save”, saving you the loss of hours of typing on a big e-mail when the browser suddenly crashes. And surely, they do crash.

Well I agree mostly except, I bank with two UK Banks, Natwest and Halifax. Both offer a Session Timeout Feature, Natwest is an opt out function, but I like both of them.

Natwest, 5 minutes, log out, back to log in screen but with Halifax, the session is logged out but the data is still present on my screen, so anyone could come along and note down all the details, if they select anything they are warned to log back in.

I actually like this feature in places.

Sarkie.

ATM machines annoy me for the same reason! I should be able to insert my card, punch in my PIN number - then walk away for a few hours, come back, finish the transaction, and walk away with my money.

If anyone else just happens to walk past during that time, I should expect they’ll see that it’s in use and not use it either.

Ok maybe that’s a bit over the top - but the principle remains. As an educated user, you don’t want to be logged out of web applications. Think of the uneducated users however that may use applications in a fairly public setting and walk away - exposing their email.

As a lot of people have many of their social networking accounts and other accounts linked to their web mail - all you need is access to their email and you have all the passwords for all the possible web applications that user may need.

There should be some middle ground - like data persisting over a time out (after relogging in), but to in no way protect against unauthorised physical access to the terminal isn’t right.

I HATE being logged out do to inactivity if I’m sitting at my desk and go to look at something else. However, I also understand the need to keep certain applications secure (banking etc), so the auto-logout is necessary.

Perhaps one solution to this problem would be a “keep me logged in” check box, that isn’t checked by default, but when it is, does the heartbeat like Jeff talks about. This would allow those of us that want to keep the session alive to do so. However, I don’t think this will pass muster w/the security Nazis of some institutions. We would probably still have to throw them a bone and set a timeout, but it wouldn’t be for a short time (say you’ve been idle for 2 hours). Now, when you get logged off this time, you’ve been idle for a really long time, and you probably should be logged off. However, it wouldn’t be a “typical” logoff. Instead, it would write an encrypted cookie that contained all the pertinent information needed (if possible), then the login process would look for this cookie, and would restore you to the proper state (yes, I know this isn’t possible for everything…but it is better than what we have now).

I think this has a lot to do with how “modern” web applications are built. Most examples I see of web apps (at least in the Java world) involve holding lots of things in memory. User beans, session beans, application beans, pinto beans, all floating around in memory…it’s just nuts.

What needs to be done is use a database (and all non-trivial web apps probably have a database or two anyway) to hold all this session stuff. Maybe things could be cached to make things faster for more active users, but don’t drop the session after X minutes of inactivity.

Truthfully, there probably isn’t a need to cache the session either. Given that we’re talking about transferring data over the internet there’s going to be a significant delay anyway. Let the database itself maintain the cache - the penalty to reads from the database are minor compared to the network penalty.

What we should do is allow a read-only version of your site (that still requires a login to see). Then when you want to submit data, if you’re session has expired, prompt for a login using a javascript popup, then continue the data submission. This allows for multiple levels of security on a site making it only slightly inconvenient if you’ve been idle for a long time.

http://en.wikipedia.org/wiki/Cross-site_request_forgery

One of the main reasons sites with important user data have an interest in you being un-authenticated as soon as you’re done using their service, HTTPS or not. To assume that on the open web, especially with people using IE, and especially considering most people probably don’t do updates — that you are the only one who makes requests on your machine, is silly. Mom and pop visit that spam link and suddenly make a bank transfer without every knowing better.