Cookies and Session variables are two ways, implementation members areas and user login/security. The two methods are a bargain between server performance and security. Server side security gives better security but is just not practical for larger number of users and can seriously deteriorate server performance. On the other hand user side security is far more efficient and lighter on the server however is far more susceptible to security breaches.
Although I assume a basic knowledge of what cookies and sessions are, we start with a quick review.
“HTTP cookies, more commonly referred to as Web cookies, tracking cookies or just cookies, are parcels of text sent by a server to a Web clientbrowser) and then sent back unchanged by client each time it accesses that server. HTTP cookies are used for authenticating, session tracking (state maintenance), and maintaining specific information about users, such as site preferences or the contents of their electronic shopping carts. The term “cookie” is derived from “magic cookie,” a well-known concept in UNIX computing which inspired both the idea and the name of HTTP cookies. Some alternatives to cookies exist, but each has its own uses, advantages, and drawbacks.” (usually a
– Wikipedia (http://en.wikipedia.org/wiki/HTTP_cookie)
“In computer science, in particular networking, a session is a semi-permanent interactive information exchange, also known as a dialogue, a conversation or a meeting, between two or more communicating devices, or between a computer and user (see Login session). A session is set up or established at a certain point in time, and torn down at a later point in time. An established communication session may involve more than one message in each direction. A session is typically, but not always, stateful, meaning that at least one of the communicating parts needs to save information about the session history in order to be able to communicate, as opposed to stateless communication, where the communication consists of independent requests with responses.
…
HTTP sessions, which may allow dynamic web pages, i.e. interactive web pages, as opposed to static web pages.”
–Wikipedia (http://en.wikipedia.org/wiki/Session_(computer_science))
“Server side web sessions
Server-side sessions are handy and efficient, but can become difficult to handle in conjunction with load-balancing/high-availability systems and are not usable at all in embedded systems with no storage. The load-balancing problem can be solved by using shared storage or by applying forced peering between each client and a single server in the cluster, although this can compromise system efficiency and load distribution.
A method of using server-side sessions in systems without mass-storage is to reserve a portion of RAM for storage of session data. This method is applicable for servers with a limited number of clients (e.g. router or access point with infrequent or disallowed access to more than one client at a time).
In the two scenarios above, using client-side sessions could provide advantages over server-side sessions: in the first case by removing the limitations applied to load-balancing algorithms (which usually translates to load distribution optimisation), and in the second case by allowing the use of sessions in web applications when server disk space or RAM is not available or sufficient for this storage.”
–Wikipedia (http://en.wikipedia.org/wiki/Session_(computer_science))
Now that we have enough insight into what server side and user side security and session maintenance means, we can get down to the business of comparing the two. As it is evident up to here that the server side security (web sessions) are far more secure. There is no information that can be changed by the user, unless of course your server is hacked but then “…you have a bigger fish to fry…”, log in sessions would be the leasat of your worries. The drawback however is that the server must maintain all the information of the sessions, that too in the RAM. This can be a considerable over head for the server, not to mention can degrade performance to a great extent and may even cause the server to run out of memory. On the other hand if the session variables are to be maintained jointly on the user system and the server, this over head is avoided. The problem however is that ’smart’ users can control what cookies they send, thereby compromising security. Forging cookies is the most common way the user accounts are hacked. I sill remember the enormous number of articles on the internet regarding hacking hotmail account using cookies till hotmail solved the problem*.
Cookie based security is the most widely used these days and seems to be the clear ‘practical’ winner in the face off. However, it clearly is less secure. So I put up these questions as some food for thought.
Since the main problem with server side security is that of memory use over head. What if web languages like PHP, C# etc provide a way to store the session information on permanent storage and implement a simple ‘cache’ like system to keep only the recently used information in the RAM (Though I would suggest that the recently used information be dicarded to permanent storage if needed). This would make the server a little slower but would surely be far more secure.
PS: * How did hotmail solve the problem?
