What I do not understand is why doesn’t the server store more cookies in the client’s web browser, instead of just the SESSION_ID? I know that cookies have a limit, but how much data do you really need to store in a user’s session?
Session timeout is only necessary because we can’t authenticate the current user behind the keyboard. There is no way we can do that reliably, at least in the foreseeable future.
We can only ease the suffering - hardware authentication comes to mind. And even there you might want to protect users against accidentally leaving their key.
Go to any local midrange restaurant. Order a beverage, and look at the menu. See if the waitress will wait an hour for you to complete your order.
Local applications (like Excel) run exclusively on your hardware, burning your resources.Remote applications do not. Security implications aside, It’s economics, pure and simple.
Value-added webapps will offer an option to save form data, or do so automatically, but this costs slightly more in development.
Sometimes, on the infrequent occasion when I have a form that times out, I can sometimes use the browser’s ‘back’ button to get back at all the nice prefilled form data. I open a new session and form in a new tab, and, if the fields are arranged nicely and logically, I can use keyboard shortcuts to swap between old form and new form, cutting and pasting away. PITA, but better than nothing (esp. on longer forms).
“your users will not be dedicating their entire lives to using your web application in a punctual and timely manner”
No, but if I see a long and complex form, I will try and arrange to use it in a punctual and timely manner. You must be hell on waitresses and other service people, Jeff. That comment makes me wonder if you accept cell phone calls when at a restaurant or bank or the checkout lane of the market.
How about the birthday paradox?
Hacker could apply that to sessions identifiers as well.
I think you need a little more stuff than that if you want banks to care for session timeouts.
@Russ
"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?"
Aaaaaaaaaaand this is why so many web applications suck. “This is the way I do it” and “no one would ever do it that way” are practically mantras of so many programmers, even in the middle of Jeff’s blog surrounded by entries on the necessity of usability testing with real people and genuine arguments.
To everyone: Stop positing bank websites and extrapolating behavior of everything else from them! Banks and other sites should take every measure to protect you financially, but shouldn’t inconvenience you out of laziness! And why is everyone ignoring Jeff’s suggestion that sessions should timeout without dropping state on the floor?
Myspace is one of very few sites that are good in this regard. If you get timed out or need to log in, it’ll take you right back to the page you were accessing after. (It won’t send the message/comment if you were writing one, but at least it won’t clear it when you page back.)
A banking application is maybe just one exception why you should have a time out in a web application. A bank wants to cover itself and be sure that your money can only be transferred by you when you are logged in.
I only want to loose my session if I close my browser. For the rest, keep my application alive.
Another reason for session timeouts, that you didn’t mention, is shared computers. Possibility of leaving a banking page open and forgetting about it in a place like internet-cafe calls for expiring sessions.
There are so many applications you can get timed out of especially if you are using secure networks.
It is a pet hate of mine to have log back into half dozen networks/applications every time I leave the computer for half an hour or more.
Cracker http://www.dragonlaseres.com
No timeout = ability to do a DOS attack on many sites.
One example: an airline. You book a seat, take the transaction to teh credit card input stage, and then walk away. That seat – on a specific flight, leaving later today – is being held for you, pending you completing the transaction.
Do the same on a couple of dozen PCs for the same flight (or the same PC via an anonymising service).
Result: you have prevented the sale of half the seats in an otherwise busy flight.
I also agree with Benedict. Sessions go against the stateless principle of HTTP and REST and should be avoided.
Very true and, IMO, the best arguement for user education. You can provide them a faux sense of security with session timeouts or you can educate them. In the meantime, the least you can do is make the timeouts non-intrusive to their experience with your web-app.
I usualy make the page ask again for the usr and passwd and when they are correct then the user is taken to the place where it was "last seen"
This has a drawback if you have some sort of form that was not submited…it will be cleared…but better than nothing 
Security through wishful thinking and misguided notions.
Since this is allegedly a forum for tech-minded folks, lets make the differentiation, because a lot of the comments talk about sessions in the abstract, waitress analogy that has nothing to do with technology or with what a session really is.
A quick recap:
FTP is stateful. Once a user connects to an ftp server, they authenticate and a connection stays open for the length of their visit. If you disconnect / close / lose the connection, you have to re-authenticate the next time. FTP servers routinely disconnect idle connections.
HTTP is stateless, so a web app has no natural means of identifying one user to the next. A connection is made to a web app to retrieve a document. Interactive, static, ajax, gif, jpg, mp3. whatever, it’s still a document and only a document.
Ah, but then came HTTP cookies, little chunks of data that are persisted by the client. Cookies are given names, contain data, and have lifetimes (they are essentially persistent with some variations). All the cookies for a website are sent on each request (for a document) and returned on each response (the document data).
Authentication (cookie) - when a user proves to the web app who they are, the web app gives them an authentication cookie. This enables the web app to identify the owner without re-requesting authentication on every document request. There’s no universal authentication cookie, it’s just a ‘special’ cookie that the web application knows about. (forgive me for ignoring other authentication methods)
So, given that background …
Session - typically referred to as data stored on the server for each uniquely identified user. From the perspective of the web application, it’s globally accessible data for the user that survives document requests, and gives the illusion of ‘state’. Bad programmers often chuck all sorts of junk into the session naively thinking it makes things easier for them (shopping carts, recordsets, etc). Early / basic implementations of the session just store the data in normal memory.
Now, a server has an upper limit on memory available. If sessions are used, the number of unique clients it can service is directly proportional to the size of session data. Back in the day, when the only session was in-memory, people realized after their servers fell over that it wasn’t a good idea to hold onto this forever and decided that perhaps expiring sessions was a good idea. How long though? A question that was never answered correctly.
Another issue with using sessions and in-memory session data is that it doesn’t scale out, only up. I.e. you can only get 1 massive computer, a single point of failure, and far more expensive, instead of adding farms of low end servers that can use cheaper components, and only adding more computers to the farm when necessary.
While scaling out is still better, other smart people have come up with other ways to (ab)use session data, but still have it scalable. I’ll pick on ASP.NET just because I’m an old droid and can no longer grok php/ruby or linux. Sessions State Servers, Sql State Servers, and even the ability to create your own home-brew state server. All can allow farms of servers to act like they share the same old in-memory session data. Load balancers can also sustain the illusion by using sticky sessions (rerouting the same user to the same machine each time) But I digress, these are all band-aids provided by vendors to allow sloppy programming practices to continue.
The term session timeout stems from when the sessions were in-memory and sessions NEEDED to timeout. As pointed out above the world has moved on. Sorry for shouting but SESSIONS NEED NEVER TIMEOUT. Not that you should use sessions anyways, lazy programmer in the corner picking your nose, pay attention.
So, for the love of Pete, don’t use sessions. Don’t expire sessions. Don’t abuse and rely on sessions with the misguided notion that they are some sort of security feature.
“Session hijacking” can occur anytime, so relying on timeouts isn’t a solution. It only decreases the likely attack window, but that’s about it. Do your homework.
Finally, what many people are alluding to is timeout of the authentication cookie (sometimes also called a ticket). As the smart people point out, when the need arises, mimic successful websites who obviously paid someone to do some usability testing. Amazon remembers you indefinitely, but does ask you to authenticate when you go into places like credit cards, account details, etc. Do the same. Force a user to re-type their password when necessary.
Most of the time people don’t want to be logged in as someone else. Most of the time people turn off their computers when they’re done. Most people don’t live in dodgy internet cafe’s. You can’t force security on people.
i.e. Insurance company selling online stuff.
- buy new policy - OK ask to verify on ‘buy now’
- view policy - No, who cares. It’s probably just boilerplate text in a pdf anyways.
- cancel policy - OK verify, it likely matters
- submit claim - OK, probably a good place as well
- view account - nah
- edit account - OK, also a good idea.
- send a question to online support - again, who cares.
- other random surfing around site - who cares. Everyone has insurance policies, so what’s the secret?
- likelihood of logging in at a dodgy internet cafe? 0.01%
Now before someone complains that ‘I don’t want to log in every time I do something’ think of anyone but the tester. In most normal usage scenarios, a user will only get prompted once or twice on their visit.
In the banking scenario, fine. It’s not sessions though, it’s inactivity. Sit idle for x minutes, warn user. If no response ‘log out’. Note that you can’t rely on people to log out either, so that authentication ticket is sent to the server the next time, and it still needs to check when the user last did something. If that something was x minutes ago, force them to login first. Does that mean they can’t be at the same place they were before?
You don’t have to keep them logged-in forever. Even Google makes you re-authenticate once a month regardless of how often you use their service.
One last word on Internet Cafe’s. Reputable / decent one’s i’ve been to reset the OS from scratch every time someone logs out. If you’re in some dodgy place using the internet, how can you even be sure there aren’t keyloggers present? what about video camera’s recording what you type? You’ll never be secure in those situations.
Think a timeout’s gonna help you there? Is a timeout going to stop your kids from unplugging the cable and delving into browser history (hint most browsers will give you the last version of the page, which is still all the pages you visited while preciously logged-in). Your rubbish timeout doesn’t help there either. Maybe you can prevent this in some browsers, but it’s not a universal feature, so like everything else in web app land, you program to the lowest common denominator.
Sessions are evil. Session timeout is evil. If you don’t get that by now, change careers.
My bank, HSBC, recently introduced a neat feature into its online banking. If you haven’t done anything for five minutes, it pops up a window asking you if you wish to stay logged in, with a one-minute countdown. That way you don’t need to worry if you have to leave your computer alone, and if you need the session to stay alive (say because you’re working something out to do with your old transactions onscreen) it lets you do that.
For financial companies PCI Compliance requires that all websites have session timeouts of no greater than 15 minutes. Even if everything is HTTPS we still have to kill the session.
However to be Section 508 compliant we also have to give a pop up warning the user their session is about to expire. So the user experience is one of many annoying alerts instead of many annoying logins.
I dream of a day when a usability expert is included in all of these compliance discussions.
And, besides this, i think the real problem here is, that there are
forms which are that huge and painfull to fill that the user takes more than 5 Minutes.
What are they for, doing the tax declaration?
How about a web posting? Perhaps you are sharp enough to craft a readable web post you are satisfied with in 5 minutes or less every time. A lot of us are not.
It amazes me how many people here are missing the point. Sure there are situations where its a good idea to reauthenticate the user every now and then. (Almost) noboby’s arguing that. But I don’t need that level of security in a message board, or a web game. Just have a little sense. If someone in my house walks by my PC and posts something stupid in my name on the WoW forums, I’ll just go smack them around until they get the idea not to do that anymore. I don’t need your help to stop them.
There’s an underlying issue here I think that relates to security. I’ve seen it in lots of other spheres too. I know we developers tend to think our programs are Very Important, because we devote large parts of our lives to crafting them. But at some point we really have to get over ourselves.
Not everything our programs do is worthy of retinal-scan biometric security access. Nobody wants to hack your user’s crappy game sessions.
Not every program’s sources are so innovative that they need to be zealously shielded from prying eyes, and refuse to even install if a debugger is installed. More likely if they saw your source code your customers would laugh themselves sick and your competitors would go broke trying to copy it and get it to work.
Not every program is so sensitive that it needs a license manager and a $3000 dongle system that has its own internal clock (so that cretin user can’t just set the clock back when the license expires). If someone makes a bootleg of your recipe-management program, the nation’s terrorist atlert system won’t go from yellow to orange. Honest.
So please have a sense of perspective, and be nice to your poor users.
I wonder if we should, as an industry, look at this in a totally different light?
Instead of expecting users to accommodate our security needs let’s do it ourselves. Instead of assuming “everyone does it this way” let’s make room for every use.
How? My idea is to model it more like the physical world. As Neil said, you don’t leave your keys in your running car when you go into the store so why leave your bank logged in when you walk away from any computer that doesn’t have physical security such as a cafe? (If the cafe locks you out when your time is up then do the important stuff first and surf the news at the end so if it locks it’s no loss)
ATMs have limits. Mine only allows $200 per day to be withdrawn which limits the bank’s loss in case of fraud. Why not the website? Any bill payment or fund transfer over $X requires a login. Queue up the 5 bills you have to pay and put in your password again to commit the payment and it’s all good. It’s a pain to have to do the extra password but it’s what we are used to - if it’s over a certain amount you have to prove yourself. I could walk into my bank with a check for $30 and they probably wouldn’t even ask for ID. If it was $30,000 they would want a fingerprint and a DNA test to prove who I am. (ok, I exaggerate but you get my point.)
Also mentioned is that no session timeout is really all that safe. If I’m at a cyber cafe and my time is up there is a great chance that someone is right there ready to use the system. No 5 minute timeout will help there. It’s especially true in the more poor places such as West Africa where practically no one has a computer but many people use one at a cafe.
In fact, because I don’t know the owners of the cafe and how the system is secured, I’d be hard pressed to even use a public terminal for sensitive actions such as banking… but I’d surely be as careful as possible if I had to do it there. Don’t you watch over your shoulder at the ATM? Mine has mirrors and it’s my favorite feature - I can see if someone is looking over my shoulder or raring back with a fist aimed at my head.
It’s time that we developers take the stance that in today’s environment we should accommodate the end user’s needs and bend to their habits as much as possible. We are no longer in the elitist 1970’s where we are computer gods and you’ll do it our way and like it. Originally the telephone was only one style. Now there are small phones, big phones, lit phones, phones with monstrous buttons, amplified phones, etc. As they became commonplace they adapted to the needs of the users - it’s time for programs to do the same.
Gee, this is getting a bit long - I sure hope my session doesn’t time out. lol
And I thought I was distractible! What kind of ADD must you have to walk away for hours or days from something like banking? Timeouts do suck, though.
I don’t leave my PC on unless I am actually working on it. I even turn off the modem and other stuff most times like speakers and so on it saves a lot of electric. I guess i’m not much fun for launching attacks even if i was hijacked. Never could be sure if i’d be on. I took the safety test and it says my PC is locked up tighter than fort knox, yet i still feel a little insecure banking online no matter what i do.
I support the right tool for the job approach, make things as secure as they need to be, no more or less. That would save some of the daily frustration.
For all those (including myself) who are paranoid about the having all the data available on the screen for anyone to see, we can implement a simple “lock screen” layer on top of original layer where user would need to re-authenticate him/herself after x minutes of inactivity.
After authentication (which would be a ajax server call), the lock layer would go off, and user is back to his/her screen with all data intact.
Sure, most anoying is loosing the data in form. Want it solved foor you on most sites word-wide in fiwe minutes? Use Opera and data entered to website will newer be lost by expired sessions.
Situation: you fill a form and send it when session expires.
On most sites, I need to enter login/password, press back button on my mouse, I see the filled in form and just click ok. Done.
On ugliest sites wordwide I press the back button twice, see the form with data filled, copy them to notepad, navigate to that form again and paste them field by field.