Session and Cookies
There are three scenarios for using cookies to track persistent connections: 1) security and convenience are minor issues, 2) security of the connection is important, but physical access to the user's computer is assumed to be secure, or at least, entirely the user's responsibility, 3) the website needs to support users who do not have exclusive physical access to every pc they might use. You might also need to provide session for users who turn cookies off.
Where security is a minor issue – where access to free content is the only consideration – one cookie will do. Log in and let the cookie stay on that computer forever.
Where physical access to the computer is secure, for ecommerce you just need one additional cookie that the browser only sends when the connection is secure. Bad guys could pretend to be the user in the insecure areas of the website, but they couldn't use the secure areas – account management, purchases, etc.
The third case is the most challenging. What if your customer may connect to your site from an office environment where many people have physical access to the computer, or even share the same computer during the course of the day?
In this case, the customer must be able to log out. And before actually making a transaction, the customer should enter a password again.
To support logging out adequately, you need two session cookies: one that times out at a certain point in the future, and one that is deleted when the browser closes. A customer could reasonably expect that closing the browser will end the session. If there is only a timed cookie, the customer could close the browser and walk away feeling safe, but someone starting the browser again before the cookie expires would still have the customer's session.
You also need a cookie that is only sent over a secure connection. This is the cookie that can be trusted as the actual identity of the customer.
At this point, there is still a hole in the system. When a customer closes the browser to end the session – rather than explicitly logging out, which should remove all the cookies – a bad guy could re-insert the cookies to keep the session going. This is the situation in which you can't trust the secure cookie. For this case, you should require a password before actually committing a transaction.
Further, in this situation you shouldn't rely on client-side cookies for the time-out. Your server should track session time-outs. So actually, the time-out cookie is superfluous for security. (It may still be cheaper to check for an incoming cookie than query a session database, so you might want to check for the cookie first, but then also check the database if the cookie is present.
Log out, in this third case should be done on the secure server, and remove any cookies used to identify session.
You may want other cookies that are permanent. To know which of your customers have used which browser is helpful, and you can certainly use customer preferences without requiring login, if they've ever used that browser before.
Copyright © 1998-2011 J. R. Boynton