Login systems: Why are sessions needed?

Question

I was creating a login system with PHP and I wondered: Why are sessions needed?

If I store a cookie with the userid and the sessionid doesn't it pose the exact same security risks to storing a cookie with userid and password hash (given that the password hash is strong enough)? Yeah, someone could potentially steal the cookie, but isn't it the same if they steal the sessionid cookie?

Could someone tell me what's the reason for using sessions in every (reasonably secure) login system?

Answer 1

One of the benefits of a session is that you can generate a new one each time somebody logs in, and even periodically during a user's visit. If you just used userid and some hash of the password, then as soon as somebody stole your cookies they would be able to log in as you indefinitely. Sessions expire.

Answer 2

Cookies you can set to expire immediately, or a year from now if you wanted to. Sessions expire immediately when the browser is closed. They are generally more secure because of this. There really is no difference that matters in this particular scenario - except for the length of expiry, and the fact that one is stored 'physically' on the client machine, while the other is stored in memory.

Answer 3

Because is more secure period.

With sessions the information is store in the server, therefore it would take another few steps if someone is to still any kind of information. With cookies anyone can get the indformation straight from the local machine without the need of server requests.

Answer 4

Rather than creating a hash, why not encrypt the session id, so that you can decrypt it and see if it timed out.

If you also have it tied to an IP address then you can make it more secure.

Or, you can have the user just log in for every page they want to go to.

Once solution is to have a javascript app that actually gets all the information for the user, so, the username/password is stored in javascript. Then, for every page request, or interaction, pass either the username/password, or a token that was the result of some initial authentication, that is also encrypted as above.

Then you don't need a session, and if the user closes that tab, their information is gone, so there is no security risk.

Session ids are simpler than having javascript do everything, so, most people opt for sessions, but, you don't have to.

Answer 5

If I store a cookie with the userid and the sessionid doesn't it pose the exact same security risks to storing a cookie with userid and password hash (given that the password hash is strong enough)? Yeah, someone could potentially steal the cookie, but isn't it the same if they steal the sessionid cookie?

Yes, it's potentially a similar risk. Stealing a cookie may be argued not be as serious for several reasons:

• Session cookies have a shorter lifetime.
• Users frequently recycle username/passwords between sites, this can expose them more if their credentials are intercepted.
• A session may actually not allow the user to do the same things as a username/password; for instance, the site may require the user to re-enter his credentials at some point.
• The site may limit the session validity to one specific IP.

But yes, having a session cookie stolen may in some circumstances be as serious as having username/pass stolen. To have solid security against stolen credentials, you must encrypt (https) all the traffic between the users and the web server (even before they authenticate, otherwise an active attacker could change the action of the form submission where the user enters the credentials in order to make them not be posted through a secure channel).

Answer 6

You describe a design where the user credentials are validated on every page request and the login form is only used to store these credentials in the browser. I see several issues with such unusual approach:

• You transmit sensitive information on every HTTP request.
• In order to validate the credentials you possibly have to run a database query and you do it again and again and again.
• You have to validate the credentials just to know who the request comes from.
• Simultaneous connections with the same credentials will share data [see addendum].

It's more typical to validate the user once (possibly using an encrypted channel or hashed information) and remember it for a specified time.

Whatever, sessions and cookies are completely different tools. Cookies are a client-side storage while sessions are server-side. They only relate each other because the most typical session implementation uses cookies to store the session ID (since HTTP is a stateless protocol, you need such tricks to keep track of what request come from whom). The benefic of server-side storage is that you have full control on it:

• You can use as much space as you need.
• You can use whatever data format you need.
• You can keep sensitive data or stuff you don't want to the user to see or mangle.
• You can trust the information since you put it there.

Addendum

In a classical session system where you assign a random ID on session start a registered user can have many simultaneous session instances in different computers (or even in a single computer, e.g., one in Firefox and three more in Chrome incognito mode windows). If you only identify the visitor by his username, the user will only have one session: if he goes home for lunch he will find the session he left at work, if he shares his password with a friend he'll see what his friend is doing. This can be considered a bug or a feature and, of course, there're many tricks to prevent it. Just take it into account.