Session vs Cookie Authentication

Question

Here what I means by the two :

Session Authentication : Stored "Is authenticated" state in a session variable.

Cookie Authentication : Stored "Is authenticated" state in a cookie protected from temper by HMAC.

Question : Is there any advantage to one way versus the other one from a security point of view?

The best reason I seem to find for the cookie approach is that the server has to store less data, which is unrelated to security.

Extra notes

Let's say you tell me that using cookie authentication is better...

I have seen so many web applications that use cookie authentication but fail to link it with the session. It's a problem because they store the user information like his access in the session. So, you can build a simple attack like login on your own account that has barely no permission, then steal the session cookie from an admin and then impersonate him.

By that, I mean that whatever strength the cookie based scheme had over the session approach, it just lost it (because of poor session management). In a scenario like above, a cookie based approach bring nothing security wise.

Answer 1

I am not a big fan of the cookie authentication as you had outlined.

Session authentication assigns a random token to the client that has no meaning other than being a pointer to the session information stored on the server. The primary problems being low entropy for token generation.

However, cookie authentication tends to have more issues. Because the information in the cookie carries sensitive data with it, it must have some sort of HMAC solution with it to prevent tampering. Ruby on Rails does this, and they've had cryptography issues and code execution issues. Play framework does this, and they've had cryptography issues and code execution issues. Such a mechanism can work when done right, but in these two examples, getting it wrong can be disastrous.

Answer 2

I would prefer session based authentication every time. A cookie is not a good option.

As @HexTitan said, I am not a fan of cookie authentication too. It's easy (to a extent) to break its security. Bruteforcing a cookie until it spills some secret is not that hard.

On the other hand, you must be sure that your sessions have sufficient entropy. If they don't, any attacker can start multiple connections to your server, get the session id, and see how they correlate. Having poor entropy can lead to session prediction.

Outside of the security point of view, you can store far more data in a session than on a cookie. You will reduce the traffic on your server too, as every single request will send the cookie back, and if your page have 135 images, 10 scripts and 5 css stylesheets, the cookie will be sent back 150 times just for the home page.

If storage space is a concern, you can bzip ou gzip the session data, and decrease the storage requeriments. Having a short session lifetime (~2h) will help too. For example, PHP usually cleans out expired sessions every couple hours.

Answer 3

i believe that this failure to connect to the user session can be overcome by including the TCP Socket information as a variable during the creation of the cookie. but, as a cookie is just a key/value pair, it all depends on the specific implementation on the server.