Your Session Has Timed Out

@Jeroen:
The computer auto-locking after X minutes would make a lot more sense
than all your browser sessions expiring after X minutes.

Of course, but if you’re the responsible man in the bank or online-shop-administration, you would let expire sessions in spite of beeing sued afterwards and be responsible for a punitive damage of some milliions.
The complainer could argue that it is “state of the art” to let sessions time out, and that you have not.
That Windows or Linux could handle this by locking the workstation is often unknown to infrequent pc-users.

If it’s only facebook, don’t time out.
If it’s financial data, time out if the user has taken no action for about 20 or 15 minutes. Or you should have big cash reserves to donate.
Of course you should persist as much as possible and preserve state.

When my users’ sessions time out while posting a form, I show instructions on how to preserve their data: login in a new window, then return to this page and refresh to re-post the data.

I agree with Brett - Cross-Site Request Forgery (XSRF / CSRF) is the one compelling reason to time out a users authentication session. The longer users are left in an authenticated state, the larger the window is for CSRF attacks.

However, that does not mean the entire session needs to be destroyed after a short timeout - as Joshua says, simply ask the user to re-enter their password after a period of inactivity, like many internet banking systems do.

On the CSRF topic - always make sure state-changing actions (e.g. send email, transfers money) only respond to POST requests. It is trivial to cause CSRF GET requests using image tags etc, but tricker (not impossible) to force CSRF POST requests. For further security, require that the POST request contains a dynamic token which was included in the originating form - such as the users current session ID - to thwart one-size-fits-all CSRF attacks.

Sorry for the tangent, but the more web developers that are aware of this, the better.

I work in the medical industry, and for us timeouts are a security feature. (On our app, we originally had it set to ~2 hours, and then had to reduce it due to security concerns.) We allow users to save partial data, since it could concievably be weeks to get some items needed on a form, if it’s something that will have to be verified by someone in a lab or clinic. (We do pop up a message box to let the user know that their session’s about to expire.) Shared computers aren’t just a worry in internet cafes. Nursing pods also often have shared computers, which are regularly left unattended, as the nurses do their real work.
I’ve also worked on desktop apps that would log you out after 30 minutes of inactivity. It was a common enough requirement that it was supported by our tool set.

I want to say that https will not prevent session hijacking. Session hijacking is rarely done by sniffing the packets that go from the users computer to the server. This wouldn’t be really fruitful, as there would be literally billions of packets to sniff. The most used methods are Cross-site scripting and session fixation. This way they will get their hands on the session id and can easily recreate the session cookie.

http://en.wikipedia.org/wiki/Session_hijacking#Methods

No type of encryption will be able to do away with this, as it is done on the users computer. So what other options are there? Since the hacker doesn’t know the time of login for the user, it will be hard to log in right after they do. So a timeout will actually be the most effective way (other then asking for a password every time the user does something, which I would find even more annoying)

That said, for websites where security is not as high of an importance as a bank, sessions should not have to time out. Or you should at least have the “remember me” option. Where a new session is created automatically for you.

What I like to do is similar to solution #1 in your post. If I know my session timeout is 20 minutes, I will add a javascript timer on my page that will be for 18 or 19 minutes. When it reaches zero, I pop up a javascript confirmation window to the user asking if they are still working on the form. If they click yes, then it causes a postback, thus renewing their timeout. If they don’t click yes, or click no, their session times out (probably because they left the computer). This works particularly well for a survey website I made. Users hate it when they spend 20 minutes (or more) filling out a survey with additional comments for each question just to have the session timeout.

Let’s see here…

IP = stateless
TCP/IP = built on IP, stateful
HTTP = built on TCP, stateless
WebApp = build on HTTP, stateful

…what’s wrong with this picture? Might it have something to do with why the web is so goddamn slow?

And what’s next? Is some genius goiung to find a ‘clever’ way to add a stateless layer on top of web apps?

Thank you so much for addressing this.

I can kind of understand it with my bank. After all, Bank of America has to be under a constant barrage of attacks, and it would really ruin my life for a while if one managed to succeed against my account.

But for a lot of applications its just stupid. For instance, the little online web game I play at home. Its realtime, and resource collection based, so the typical workflow is to issue a couple of commands, then wait an hour or two before doing it again (or go to work or bed and check again when next near the machine). That means pretty much every time I get the session expired message. Why even bother in that case? You might as well just get rid of the “session expired” page and make me relog in after every command. Its still massively stupid, but it would at least save me clicks into and out of that “session expired” page.

The worst I’ve seen is the World of Warcraft forums. The session timeout there is something like 10 minutes. For a flip little message, that’s fine I suppose. But often it happens that I have a post I want very much to get right. (EG: A detailed explanation of a bug I’m having trouble with) I spend a lot of time editing and rephrasing it to get it just right. Then when I’m finally satisfied I click the post (or preview) button, only to get a “session expired” message. The back button simply takes me back to the posting interface with a blank text edit box. All my work is gone! That is so frustrating.

I’ve actually taken to composing posts in emacs and pasting them in the edit box when I’m ready. I just can’t trust my content to Blizzard’s user interface. But sometimes I forget and loose another 20 minutes of work. Grrrrr.

Seriously, unless you are Bank of America, don’t do this.

Jeff, do you ever revisit these topics after the answer to your question is clearly explained in the comments?

XSS and CSRF are the reason why sessions should time out on the web. Yes, it’d be great if web security were better/easier, but the reality is that it currently isn’t. You’ve left a lot of people saying “YEAH! WHAT JEFF SAID! THOSE WEB DEVS SUCK!” without truly understanding the problem at hand.

Unless you’d care to explain why XSS and CSRF can be ignored, it’d be nice for you to either update or post a new entry to clarify why session timeouts are a necessary “evil”.

Somebody might have mentioned this before, but I think a pretty low tech approach should be used as well. What about asking users at the very beginning with something like “Is the computer you are using now in public place?” If the answer is yes, use “paranoid mode” (eg. time out in 10 mins, as well as other security measures). If the answer is no, use “relaxed mode” (eg. time out in 3 hours).

The idea is to engage users with the concept of security right from the start, using language they can easily understand. Thus they can make qualified judgment, which we will then use in setting security measures for a particular session.

Having played with WCF in .Net 3.5 recently, I know that the above (Joshua’s comment) is probably possible using Durable Sessions without inventing too many wheels yourself. This might be a good solution to the problem.

Amen!

Not long ago, I was filling out a contact form on my bank’s website. I had a lengthly message that I was sending them, with a bunch of information about some particular transactions against my account. It took me about 20 minutes to compile the information and write the message. When I hit submit, I got a message that my session had expired. My message was not sent and I had no way to recover it.

I had to compile the information again, and type the message again (this time into Notepad) before logging back into the site and going to the contact form to paste it all in.

I complained but they basically didn’t believe me. I was supposed to have gotten a popup asking if I needed more time. A popup, seriously? With popup blockers built into every browser now, they rely on that?

-Jeff

Jeff’s post next year if session timeouts are actually removed:

Why do I always have to log out from web applications? If I login to check my mail at a public computer in the library, then leave, everybody after me can access my mail! Web sites should be smart enough to log me out automatically if I haven’t used it in a while. I shouldn’t have to remember to go through a logout process every time.”
"

I think you touched the main problem at the beginning of the text: restoring context.

Expiring cookies aren’t bad, throwing the user back to the doorstep when they have expired is. Unfortunately very few sites get this right at simply sneak the password question in before getting you to exactly the page you wanted to see.

Of course the security levels are quite different here. I quite like what they do at amazon: They’ll know how you are but require you to enter your password before placing an order or digging through your order history. Banks, however, never get anything right in this respect.

HTTPS is always a (compulsory) complement, not an alternative. However, I see your point. In online banking, the solution should be obvious: Actually, I don’t see any reason for the user to stay logged in at all. Online banking is not a continuous activity, it’s more like a set of distinct (trans-)actions and each of them should (MUST) require individual authentication (notice that this is actually the case with PIN/TAN authentication; so why bother with the classical login at all?). If you prefer comfort over security, have your browser store the login data (and preferably have the site use HTTP authentication mechanisms as opposed to HTML dialogs). The current approaches to online banking that I know are, in my humble opinion, fundamentally wrong (I could exclude SmartCard-based approaches but I’m not sure I’m going to). But as long as they continue to use the classical login mechanism, session timeout seems crucial to me.

For other, less transaction-driven applications I don’t see why the heartbeat approach shouldn’t be taken. XSS could be a valid concern. Let’s not forget that paranoia is a foundation stone of the security business.

When I took over maintaining the internal HR application of a small size company, the first complaint i got from users was that when they upload a file for one particular employee, it gets saved to a different employee! A little investigation revealed this happens when the users remained idle for about 20 minutes after logging in and then trying to upload the file… Considering the application is only used by 4 of the HR in the company, and they have their own machines, I simply extended the session time out to 2 hours, and have not got a single complaint yet.

http://ars.userfriendly.org/cartoons/?id=20080412 I was browsing a new web comic and it gave a funny side to the problem of session timing out…

Session expiration for the purposes of preventing unattended computer attacks sounds good at first, but what about non-web software such as banking tools, business information, address books, etc? That’s all just as vulnerable on an unlocked computer as web applications are.

The responsibility for securing the local access point belongs to the user, not to the application, not to the OS. Certainly the app and the OS should do their part to limit, or eliminate, weak security points, but the ultimate responsibility still lies with the user. The app is not responsible for securing an unattended, unlocked workstation any more than Ford is responsible for securing an unattended car with the keys in the ignition.

Websites that DON’T expire sessions piss me off, but then I guess that is because I work in Application Security and realize that Session Hijacking via sniffing an unencrypted channel is the lowest risk attack I need to worry about associated with the session.

If your site has cross site scripting on it, and about 80% of websites do, including the big sites out there, a simple document.cookie has now given me your session (or if you set the httponly flag in the cookie I have to jump through a hoop making a XMLHttpRequest and parse the response to get the cookie), and if that session never expires I can be leisurely about using my newly stolen session.

Or, I could put a snazzy little iframe on my site to amazon, or gmail or wherever, and since you are still logged in I can make all sorts of forged requests to those websites as you (See Brett’s post about CSRF).

And now that the retarded HTML 5 working group wants XMLHttpRequest to be cross domain and pass cookies (thankfully MS told them go go shove off about that, and now so has Mozilla) your unexpired session would be all the more useful.

Binding to an IP is of limited use considering the tremendous use of load balanced proxies in the world. AOL users, for example, are notorious for connecting over several load balanced proxies, so their IP bound sessions would be invalidated all the time. The best you can do is bind to the first three octets of the IP if you don’t want usability to completely suck, much worse than with a session occasionally expiring.

Session expiration is a necessary evil of the technology; sessions are a hack to begin with and as a result have plenty of security concerns. Yeah, it sucks for users, as does even having to use a username and password (inherently weak authentication with crap for usability- how many users really can be bothered to put an upper, lower, number and special character in their password) to sign on in the first place. However ignoring security concerns in favor of usability is a Win98 approach to things, and as I recall that ended pretty poorly.

“Is it really so unreasonable to start doing something in your web browser, walk away for an hour – maybe even for a few hours – then come back and expect things to just work?”

Yes, absolutely. This would be paramount to leaving your card in an ATM machine. Are you honestly suggesting that everyone who has access to your PC be privy to every piece of personal access you might have forgotten to close ?

Users aren’t perfect. If you don’t force them, they’ll leave their online banking site open and logged into for days (“It’s so inconvenient having to log back in every morning”), just like they will leave car keys in the car (that’s why cars make beeping sounds nowadays) or their cards in ATMs (that’s why ATMs spit out your card first). Security doors close on their own. Front doors usually lock on their own if you pull out the key and close it. SSH sessions time out after a period of inactivity. Safe doors relock themselves after 30 seconds. Windows by default goes to the login screen after the screen saver turns on.Even cellphones lock themselves if you turn them off. Why would things such as online banking be expected to behave differently ?

Of course, this applies much less to websites that are less volatile than online banking, such as forums.

“A common practice to prevent sessions to be stolen, is to bind it to a certain IP address”

This is not even nearly safe. In a public setting, most shared computers will actually have the same external IP address, with router performing Network Address Translation (NAT).