programming and human factors
by Jeff Atwood
How many times have you returned to your web browser to be greeted by this unpleasant little notification:
Your session has timed out. Please sign in again.
If you're anything like me, the answer is lots. What's worse is that you're usually kicked out of whatever page context you were working in. You have to manually log in again, remember what you were doing, then navigate back to where you were and resume your work.
Most programmers look at these sort of browser session timeouts as a necessary evil -- sometimes even as a security "feature". I know my bank website zealously logs me out of its web interface if I'm idle for more than five minutes. I'm not sure either one of these reasons are particularly justifiable.
As a programmer, I understand why session expiration occurs. The HTTP protocol that the web is built on is stateless. That means every individual request your browser sends to a web server is a newborn babe, cruelly born into a world that is utterly and completely oblivious to its existence. The way modern web applications get around this is by telling the browser to send a small, unique value back to the website with each request -- this is known as a HTTP cookie. It sounds a lot tastier than it looks:
Content-type: text/html
Cookie: SessionId=5451297120
While there are privacy concerns with cookies, it is a generally accepted practice today -- at least for the first-party cookie flavors. While it is possible to maintain state without cookies, it's painful and awkward.
Every web request to that server will include its own cookie and associated session id until it expires, usually many months or even years hence. The browser definitely isn't the forgetful party here.
It's up to the server to correlate the unique session identifier sent by the browser with your individual identity, context, settings, and preferences. This is usually stored in a database of some kind, keyed by your session identifier. For performance reasons, some chunk of session information also ends up in the server's memory; there's no need to reach all the way out to the database the next twenty-six times you obsessively refresh your Facebook profile page.
Still, that doesn't explain why the web server mysteriously forgets about us. If anything, the server has all the information it needs to remember you, even if you walked away from your computer for a week. So why does the server choose to arbitrarily forget about you in an hour?
That's the why of browser session timeouts from the programmer's perspective. But that doesn't make it right. Far from it.
As a user, I can say pretty unequivocally that session expiration sucks. 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?
As programmers, I think we can do better. It is possible. I am inundated with session timeout messages every day from a variety of sources, but I've never once seen a session expiration message from gmail, for example. Here's what I suggest:
I wish more developers would test their web applications for session timeout issues. Despite all rumors to the contrary, your users will not be dedicating their entire lives to using your web application in a punctual and timely manner. They have phone calls to take, meetings to go to, other websites and applications to attend to.
Is it really fair to kick users all the way out of your web application, or worse, blindly reject data they've submitted -- just because they were impudent enough to wait a few hours since their last supplication to the web server gods? In most web apps, the penance is awfully severe for such a common sin.
In fact, GOING FURTHER ...
If a site wanted to be really friendly, it should allow you to LOG OUT but still save your form data, to fill out later. Let's say you have to go to a meeting and you don't want to wait the mysterious "X" number of minutes until your session expires, to make SURE you are safe. And you are in a library. And you can't just lock your computer.
So just LOG OUT and when you LOG BACK IN the site can restore things exactly as you had them!
THAT would be cool. Maybe it should be called "LOG OUT AND SAVE WHAT I WAS DOING".
Greg Magarshak on April 16, 2008 10:20 AMRight before the session is abandoned I check to see if the user logged out, if so I persist session state to a table keyed on the user's login. Next time they login they we check the db for any persisted session data in the db. If there is they are asked if they want to resume their session. If they say yes, it is rebuilt from the db, if not it is destroyed in the db. The sessions expire every X minutes (no sliding expiration) unless the user responds to a "keep me signed in" popup that is displayed Y seconds before the session is abandoned. If the user does not respond to the popup in Z seconds, their form data is submitted (via ajax) and it is saved in session along with the page they were on when the session was expired.
BrianE on April 16, 2008 10:39 AMI like to be able to spend 5 hours typing a 3 line comment without my session expiring, or at least without adverse consequences if it does.
David on April 16, 2008 10:43 AMLeaving your computer without locking it is akin to walking away from your unlocked car while the keys are in it and it's still running.
Session timeouts are similar to your keys falling out of your keyswitch the radio settings and power seats reseting because you sat at a stop light too long. You need to restart the car, reconfigure the radio and move the seat back to where you had it before you can continue on your drive.
The solution here is behavior modification in terms of educating users on the nasty things that might happen if they leave a valuable asset open for all to use. Lock it when you leave it sit there or someone may just come along and steal those 8-tracks in the back seat.
Neil on April 16, 2008 10:43 AM"but I've never once seen a session expiration message from gmail"
I have, many times actually, they just redirect you to the login page
Eber Irigoyen on April 16, 2008 10:50 AMThe issue is more about balancing the timeout value with the sensitivity of the web app. Banking and highly sensitive apps should log you out quickly, but web sites of a less serious nature should change the default timeout value to something higher, like a day instead of 30 mins.
Users expect that by closing their browser, they are done with the session and it's hard to explain to them that somebody can sit down after them and pull up their session from the browser history.
Forms on the other hand should always submit without requiring a session. I usually add a hidden formfield with a MD5 hash of the user ID plus a secret salt value so I can accept forms without having to rely on a session cookie.
Sal on April 16, 2008 10:58 AMjust some thoughts...
For preventing data loss in case of session timeout, it should be browsers responsibility to keep a copy of user data, if session expires, the user can hit Back button to get its composed email text.
it would be nice if we can have some standard Logoff and Lock buttons (web site level lock as we have for OS) in the browser - like we have close on top right corner.
I agree with you, session expiration sucks big time.
But there's a case you forgot, public computers. A cyber cafe or any other public access computer, people normally don't really understand what a session really is, they walk away and they think they magicaly left gmail... but then another guy comes and now he's in control of your account. People DON'T close sessions, they don't see why and there's no way for the app to warn them when they leave.
It's not perfect, of course, someone could use the same terminal before the session expired, but well, there's no other way I can think of.
By the way Jeff, this comment form keeps showing me the same word (orange) in the Captcha... is it because it recognizes a cookie or something like that?
Petruza on April 16, 2008 11:26 AMMy captcha is "orange" too! Is that by design? Or is it a "feature"?
In response to your article:
I think we're treading dangerous waters when we seek to enable the insecure habits of lazy users. Users should be encouraged to maintain the security of their information. I agree with the plethora of posts that suggest a hybrid solution: extend state, trash session.
Also, we should look to sites that get the user experience right, instead of focussing merely on our budget banking websites. For example, consider the way Amazon.com manages state. Your session is kept alive, but your ability to perform financial or identity actions will expire after a certain time. I don't know exactly how this is implemented, but I love the fact that I can leave Amazon up for hours, and rest assured that nobody can come along and buy stuff using my account without re-logging in.
D on April 16, 2008 11:42 AMGreg Magarshak is absolutely right. Sounds like a topic for About Face 4.
Patrick McElhaney on April 16, 2008 11:44 AMsession timeouts are very, very necessary for the fact that users still routinely check their bank accounts from public terminals. until every person on earth becomes intelligent, session timeouts ain't going anywhere.
jonuts on April 16, 2008 11:52 AMWhy not give the user the option? Make him/her select whether or not they're accessing from a public or private computer? Sessions should persist on private computers, but on public machines, the user should understand that, for his/her own good, the session will terminate after time.
Brian Warshaw on April 16, 2008 11:55 AMFuck sessions. Use HTTP authentication.
Nicolas on April 16, 2008 12:01 PMI can't believe people are still bringing the "We need to educate our users" line. Look, it's not gonna happen. Users don't learn because you feel like they should know something. We have had 50 years of IT science, and users still haven't learned. Individual users learn, but users as a whole don't, not like this, not because you want them to.
The only way to get users to learn to lock their PC is if Windows would shut down instead of starting a screen saver, and even then they probably would just get a tool that "fixes" it instead of remembering to lock their PCs.
J. Stoever on April 16, 2008 12:05 PMThe age old rebuttal, "What if the user walks away from his PC?" is so tired and so nonsensical. It would only make sense the day every malicious person waits the allotted 20 or 30 minutes before sitting at the PC of the person who walked away.
The issue can only be solved by end user discipline. No 20 or 30 minute timeout or 15 minute workstation lock is going to prevent someone from sitting at the chair as soon as the legitimate user is down the hall, or out the door, or out of sight.
HardCode on April 16, 2008 12:08 PM"Create a background JavaScript process in the browser that sends regular heartbeats to the server"
Defeats the benefits of a timeout... more work for the server. Actually, even worse than disabling the time-out, as bandwidth is being used as well as memory for caching the session info.
"How are timeouts a *benefit* to the end user?"
Prevents your son buying crap on ebay using your pre-logged on Paypal account. Even vigilant users may forget to press 'Sign Out' at some point in their lives.... I know I have.
"Imagine if Microsoft Word or Excel "logged me out" if I was idle too long in a document."
Why would it? Microsoft are not responsable for such measures here. In a web app, the developers are charged with protecting the data that drives their site's back end or user data... therefore they must put such mechanisms in place. Word and Excel really arn't responsable for ensuring that your data is safe... that comes down to the IT administrator on your corporate network. With this in mind, I think it's safe to say that the source of DATA are ultimately responsable for its security, not a third party developer of a generic piece of software that has many uses in many areas.
It was suggested that it should be left up to the OS to log off the user if idle for a set length of time. This does nothing for security or performance as a website developer can not control every PC that visits, so the only alternative is a server side time out. All in all, security comes down to the end user... after all it is those people who share their passwords or enable the password save in their browser. That being said, time-outs are established primarily as a means of ensuring that the web server stays a web server and not a speed bump, as well as giving the developer/host a way out when legal actions suppose that their system is at fault when some user left their password taped to their machine.
In my case, the session timeout was a 'feature' -- or rather, something that WAS necessary.
It's a ticket purchasing system for a smaller endeavor: wherein, once you have said that you want to purchase 5 tickets -- those 5 tickets are temporarily held/reserved to prevent oversell of an event.
If you wander away and leave a half-filled out form: your session expires and your 'faux reservation' goes back out into the pool of available tickets.
N on April 16, 2008 12:19 PMThe most stupid logout occurs in Sharepoint even though your session is identified through your Windows Active Directory Account. After some inactivity, it takes you to an intermediate page, where you have to push a link to reactivate your session. How daft is that?
GUI Junkie on April 16, 2008 12:22 PM"Service is service. Speed of service is paramount. If you are idly wasting resources that could be better used servicing people who are able to be timely and punctual about their use of the resources, you are a drag on the system."
Vice versa, if it's done in a way that isn't a drag on resources, or is less of a drag than the extra money it generates, then it's worthwhile. Otherwise we may as well have no application at all, to free up all that precious cpu.
"My sanity has nothing to do with the issue. Service is service. I bet you, too, are one of 'those people' who take cellphone calls at the register, or purchase 20 items plus tobacco and alcohol at a self-checkout lane."
No, I just expect different service out of an unthinking, unfeeling machine than I would a human, and I can't understand this anthropomorphizing of the web server. You're the one basing your rationale on web application design on an industry example absolutely unrelated to the matter under discussion. I mean, if you're going to consider thirty minutes rude to a human server, then you may as well consider thirty microseconds as being rude to a web server, adjusting to its own time scale. Does it start to make sense how arbitrary the attitude is now?
Look at the shopping cart comment above and think back to how frustrated you got the last time you lost your cart over a session timeout.
See, I can write the code to transfer a session at timeout to another table, to prevent performance degradation, and load the session back into the main table on the next login (whether it's in five minutes or five years), in no time. Machines don't care if they have to hold onto things for long periods. I'm damn glad that I don't have a manager like you throwing such bizarre analogies at me when building applications - the clients are already bad enough.
Foxyshadis on April 16, 2008 12:38 PMWhat 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?
Cristian on April 16, 2008 12:50 PMSession 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.
Robert 'Groby' Blum on April 16, 2008 1:41 PMGo 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.
Tarkin on April 16, 2008 1:47 PMHow 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.
chakrit on April 16, 2008 1:52 PM@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.)
Foxyshadis on April 16, 2008 1:54 PMA 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.
dali_bude on April 17, 2008 2:09 AMThere 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
Cracker on April 17, 2008 2:13 AMNo 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.
Harry on April 17, 2008 2:17 AMI also agree with Benedict. Sessions go against the stateless principle of HTTP and REST and should be avoided.
Asbjrn Ulsberg on April 17, 2008 2:28 AM[quote]
The age old rebuttal, "What if the user walks away from his PC?" is so tired and so nonsensical. It would only make sense the day every malicious person waits the allotted 20 or 30 minutes before sitting at the PC of the person who walked away.
*snip*
HardCode on April 16, 2008 11:08 AM
[/quote]
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.
Earle Martin on April 17, 2008 7:28 AMFor 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.
Dan on April 17, 2008 7:30 AM 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.
T.E.D. on April 17, 2008 8:22 AMI 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
Jim Sewell on April 17, 2008 9:13 AMAnd 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.
Vijay Dharap on April 17, 2008 12:12 PMSure, 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.
There is also the case of timing out due to locking other resources than the server hardware. For example, in a web shop you don't want one visitor to lock some items that could be bought by another visitor whilst the first visitor was gone doing something else.
Adam on April 17, 2008 1:31 PMMy view on session timeout is, if you have very good h/w (like google) for your server then you can afford to keep the session for a long even if user is idle, and if you don’t have that kind of hardware (mainly RAM), you must use the session timeout. You can’t just make processing of other active members slow because of the idle users. Performance will surely go down as when RAM is over, then page file on disk will be used and overall performance will go down.
Anup Daware on April 22, 2008 9:17 AMTypically apps don't store state in cookies because they can be easily tampered with by a malicious user. The alternative is to store session data in the app, which generates overhead, hence auto-logging people out.
My solution in some applications is to generate a crypto keyed Hash Message Authentication Code (HMAC) of the cookie content and store that in the cookie.
Then, when the cookie is presented back to you, check the HMAC. You can now safely store all session data in plain text in the cookie, and need keep no state in the app.
Oliver on April 23, 2008 6:09 AMI am a database Administrator.And for non trivial web apps that communicate with a database having sessions extend over hours and be resumable from where they were up to,implies locking records for hours in the database.This kind of thing really impedes other transactions and is another reason why session time out is sensible.
If it didn't occur the same person may well be trying to get back in and not be able to, only to find their records still locked by their previous session!!!
Locking records in database for extended periods is a recipe for disaster. Say i wanted to update everyones salary by 10% and I cant, because all their records are constantly locked.
Database programmers try to ensure concurrency by by NOT allowing
locks to persist for extended periods.
If their "sessions" were kept open ( but not their database locks)
they would still need to re initiate these transactions to try to re aquire these ( records )locks in anycase. Besides, if in the mean time data has changed,you shouldn't be merely trying to push through their transaction as the criteria upon which they have acquired these lock and records may have changed and would lead to a different or unwanted outcome or and may well mean that they dont want to proceed with the transaction any longer. ie. it is no longer wanted or needed
eg buying a book, if the mean time the price has gone up, or a better book become available - they may no longer want to buy it,or it may be out of stock. They should have to ( not unreasonably re initiate the whole process ) - I believe most people would want and expect this.
If you want to kill performance and user satisfaction and basically kill the app - allow sessions to hold locks indefinitely.
I don't recall the URL of the blog entry, but some time ago I stumbled over a new functionality in a well-known AJAX framework, which' name I don't recall either. It offers some kind of "screen-saver" overlaying the page/application with a modal dialog, requesting to re-authenticate after a time-out with the password. When done so, modal dialog disappears and the user can continue working as when he left.
Indefinite session time out makes no sense, but usually a day or so, at least for interactive apps, makes sense. The question is whether you want to pay for it to set up the resources to hold the sessions long enough.
Cheers!
Ralf on April 27, 2008 6:21 AM@one of Paul Houle's comments, the "10-minute timeout", c.:
The library catalog Voyager does put ridiculous resource demands on a server with its web interface (RAM demands increased by a factor of 5 from one version to the next), agreed. But it, and similar software, consist of far more than that front end: It's like an iceberg, with much happening where the user doesn't see it. Gotta share resources, and many libraries aren't keen on buying the amount of RAM needed to support hundreds of long-running sessions, precisely *because* the user doesn't see it--how can you justify it to a university administration, for example? BTW, the timeout doesn't have to be 10 minutes: Some Voyager libraries have a timeout as short as three minutes and others have timeouts of 30 minutes (or more).
But as a librarian, I'm very much conditioned to think of the user's privacy, and I want to protect your privacy EVEN IF YOU ARE NOT LOGGED IN to the software. So I want that library catalog session to time out, because it isn't anybody's business what you were looking for in the catalog.
Some of you punters still don't get it. Relying on session tear-down is a bandaid to bad coding. Relying on session data and having that reliance visible to the user, at all, is bad practice.
If you have users, you store things like shopping carts, preferences, etc. You should store these indefinitely, or at least until you can tell that a user is never coming back. Storage is cheap. You would never hold any of this in 'session' unless you're an idiot. Newbies take note! What looks easy is a recipe for disaster.
Locking: No self-respecting developer should hold a database lock open between requests, let alone minutes and hours. Unless you only make single person websites, this will never scale, ever. @Mark, I pity you for the people you work with. Non-expiring sessions does not imply locking. Retaining a db lock over 1 request implies bad coding. Smells like limburger cheese left in a heating vent for a few months.
Sessions are a bad smell. You don't need in-memory 'sessions', ever. Read my previous post about what a session is. In God knows how long I've been writing websites, there's always a better, more scalable way.
Session are not the same as authentication timeouts. Most self-respecting frameworks let you re-authenticate without losing what you're working on. It's a usability thing, but maybe you just don't care about writing correct websites.
RTFM = READ The Fscking Manual
RTFM on April 30, 2008 11:02 AMOn a project that I worked on, we actually had some fancy stuff that would allow you to "resume" after a session time-out error. In summary, when you would make a request to the server after your session had timed out, you would get a lightboxed login screen. By filling the form out and submitting, the application would attempt to re-execute the request that you had originally submitted (I think the request was serialized as a hidden field on the lightboxed login form). This worked for any XMLHttpRequest. So, you could half-fill a form, go away for a year, and come back to fill the rest of the form. When you click "submit", it would ask you to authenticate, but would then successfully post your form (as long as we hadn't changed the code on the back end during your hibernation).
This was reasonably easy because we were using a custom MVC library on the server. Granted, I'm not suggesting that you develop or use a custom MVC library (ever!), but that's what we had and so we (ab)used it. The overall experience was slick. Well, I think so anyway.
Perhaps a better solution to the problem is coming with HTML5 and client-side storage. Rather than store session on the server, it might be possible to store everything you need to know on the client (as long as you validate it all before you use it on the back-end).
Use SSL client certificate instead. It is secure as SSL. The process of logging in is hidden from user, you don't see forms, don't press a submit button and such a crap, don't reload a page, are not redirected, nothing. Major browsers support SSL client certificate. *It's a shame that it is not used on web-sites.* You can even benefit from global authorization (like OpenID), because you can *safely log into different sites with the same client certificate*.
beroal on May 12, 2008 7:16 AMI like an IFRAME with a page (say HeartBeat.aspx) that serves itself as an empty page with a meta refresh... as long as the user is on any page, they keep chatting with the webserver to keep the session alive. Makes 5 minute cookies a reality.
http://www.codeproject.com/KB/session/Session_Defibrillator.aspx
Marc Brooks on May 19, 2008 4:21 AMIsnt this a simpler way to keep session alive? Use SetInterval, then include the EnableSession attribute on your web service method?
window.setInterval(KeepAlive, 300000);
[WebMethod(EnableSession = true)]
public void KeepAlive()
{ return;}
What if Cookies are turned off- I never had solution for Gmail with IE - Accidentally I turned off my cookies now I am never able to login on Gmail through IE - btw I don't like that browser always :) Mozilla is perfect for us.
Sunny on October 29, 2008 12:57 PMIn fact there is a fairly simple solution to the problem of preserving context after session expiration. Dan on May 10, 2008 10:27 PM has something nice, but there is a simpler approach that resides entirely on the server and therefore doesn't require XMLHttpRequest or indeed any Javascript at all.
In short, it involves never changing the URL, even if you need to display or process a login form, and always adding to the login form any post your page has received, using hidden fields.
A well crafted, general-purpose include module (or equivalent technology) can handle this for all (form processing or plain GET) pages in your web application, so you don't have to implement this solution on each of them individually. The same goes for the processing of the login form: every page should potentially be able to process it (the authentication logic should go into an include that every page can use if a post is detected and it contains the login and password fields).
The only elements of your form that will need special attention are file upload fields but there are solutions for these, too.
I have been using this for years, and it works perfectly. After the user is authenticated, whatever he was trying to do is performed.
Andrea on January 23, 2009 1:43 AM@jason:
For Firefox: ReloadEvery.
https://addons.mozilla.org/en-US/firefox/addon/115
Andrea on January 26, 2009 6:00 AMGood Day. Do not be awe struck by other people and try to copy them. Nobody can be you as efficiently as you can.
I am from Mauritius and learning to speak English, give please true I wrote the following sentence: If you are looking for the best online travel agency, then you just succeeded by finding sas airline tickets.
Thank you very much :P. Kabibe.
Kabibe on April 20, 2009 12:35 PMA common practice to prevent sessions to be stolen, is to bind it to a certain IP address. If someone steals such a session id (such as copy-pasting an url which has the session id as a parameter), the session still will not be recognized as yours since the IP addresses differ.
It isn't totally safe, but safe enough to take the effort to implement (it's only an additional WHERE clause for the session-retrieval-sql, guys).
Leon Mergen on February 6, 2010 10:24 PMI know what application have session timeouts. So I just quit them and start new one after a while. They don't tell me that the session has been timed out before I start doing something again. There could be at least the heart beat that shuts the application so I know that it logged me out.
Some applications that I use over intranet log me off too. Then they hide the relog button behind few clicks, which is irritating. At least give me the relog page without me having to search for it.
Don on February 6, 2010 10:24 PM@RWW
I'd just save all my changes on their documents and tell them to complain to the IT department. The fact that you are making changes and having to exit "fast enough" is absurd.
In general:
The credit card companies and banks pay dearly for fraud. If you walk away it's unlikely you will have to pay a thing. I'd prefer not to be logged out, but really you should have to deal with whatever they give you, because they are the ones at risk.
Ideally there would be something you could sign that says "I want to be logged in at all times and I'll be responsible for any and all charges, blah blah", but I guess there are legal reasons why that's not possible.
(I also think that stores should be required to check ID for every credit card purchase, and if they don't, the fraud is their responsibility. But if you want to sign something ahead of time that says "I don't want to show my ID, and if someone uses my credit card then I'll be responsible", then you should be able to do that too.)
jon on February 6, 2010 10:24 PM@T.E.D.
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.
A good habit to get into before submitting a web form with a lot of content in a text field -- a long forum post is a prime example -- is to do a Ctrl+A, Ctrl+C on the content field. (Ctrl+A does a Select All; Ctrl+C does a Clipboard Copy. The specific keystrokes may vary if you're on a platform other than Windows.) Then, if the session has timed out or something else goes wrong, at least you have a copy of the content you entered sitting on your clipboard, which you can save off somewhere locally and/or re-enter on the web form.
http://blog.jonschneider.com/2006/02/tip-ctrla-ctrlc-before-submitting-text.html
Obviously, this tip is only really applicable for "power users", and it doesn't help on a web form with many individual fields (as opposed to one primary large field), but I've still had it save me from losing content on more than occasion.
Jon Schneider on February 6, 2010 10:24 PMAnd the answer is: Don't use sessions. When user logs in, store a security token on the server and pass it down to the client (encrypt it, etc). When client posts a new request, pass the token as part of the request (hidden variable on a page). If valid, post the data, if invalid, have use authenticate again and then post the data.
Add logout feature that automatically invalidates the token.
The only thing that should expire is the token.
If not using HTTPS, I can see possibilty the token being "hijacked" by another entity, but maybe check IP Address or location of token when it was validated.
If security is really a concern, then use HTTPS and then no one can see the token.
Jon Raynor on February 6, 2010 10:24 PMI did not read *all* of the comments, but it did occur to me that "locking a workstation" is a pretty nice way to deal with "session timeout" - your applications, data, everything is persisted but completely inaccessbile until you authenticate.
You could do this on a web page to some degree, with an AJAX tool that communicates with the server and simulates session. Whenever user activity is absent for the amount of time, the AJAX tool could throw up a modal login dialog required to unlock the rest of the page.
I see some issues with this... since the server side session would be maintained by the AJAX communication, so more than just form field entries would be preserved, particularly if the AJAX tool is somehow circumvented.
Jason Beck on February 6, 2010 10:24 PMStrange nobody has mentioned rails, so I throw this out there:
http://dev.rubyonrails.org/changeset/6184
"Introduce a cookie-based session store as the Rails default. Sessions typically contain at most a user_id and flash message; both fit within the 4K cookie size limit. A secure hash is included with the cookie to ensure data integrity (a user cannot alter his user_id without knowing the secret key included in the hash). If you have more than 4K of session data or don't want your data to be visible to the user, pick another session store. Cookie-based sessions are dramatically faster than the alternatives."
Anon on February 6, 2010 10:24 PMI have been timed out by Verizon using e-mail. Why am I not given a clue like 1 min. left ). To loose a letter I have typed carefully, is not funny or customer friendly. At the time of installation of service I was not told about time-out nor was I given a term of service with such info. If Bell telephone in 1948 could tell a long distance customer ther was 1 min. left on a 3 min. call surley someone can come up with a notice to the user. Verizon is not a customer service friendly provider of service. They suck.
Pamel on February 6, 2010 10:24 PMI was wandering if it would be possible to create me a simple program to stop my online banking logging me out or do you know of such a program already in existence. Maybe just tell it to activate the browsers refresh button would do fine. I am not a programmer at all yet so i wouldn't be able to create this myself.
thank you so much in advance
jsmith07611@gmail.com
jason on February 6, 2010 10:24 PMthere is nothing worse, than a lazy client complaining that they have to click the mouse button again.
Patrick Thomas on August 3, 2010 11:20 AMThe comments to this entry are closed.
Subscribe in a reader
Subscribe via email
|
|
Traffic Stats |