How to encrypt session id in cookie?

Question

While I was reading about session hijacking articles, i learned that it would be nice to encrypt session id value that is stored in a cookie.

As far as I know, when I start a session by calling session_start(), PHP does not encrypt session id value in a cookie.

How do I encrypt session id value and then initialize session with it?

Thomasenathomasin

Can someone remove the session-encrypt tag? – Premonish

@smotchkiss // I was thinking about it as well. Sorry for the vague tag name. – Thomasenathomasin

I know this doesn't answer your question per say. But have you considered storing the IP along with the session ID and checking the IP when reading the session. This way you can be reasonably sure that computer that is providing the session id is the same that you issued the session to. – Intrude

This would be a bad thing if the user is behind a proxy (Tor, for instance) which causes their IP to change all the time. The attacker might also be behind to same IP as well (consider company firewalls, etc) – Intranuclear

@Matti Virkkunen Thanks for setting me straight. I don't have much experience in secure sessions, so I was sorta shooting from the hip. – Intrude

@Matti the possibility of weakness cannot be any reason to deny a defense! Yes. attacker might also be behind to same IP as well. But for the others is still useful. Why not to use? Where is the logic? And how much you have seen such a rotating proxies? To check users IP is always good idea. – Clambake

@Col. Shrapnel: Using your logic it's perfectly OK to mine your own camp because it increases security - of course with the downside of probably having your own guys step into them too. I'd rather use a good defense than a half-arsed one ridden with false positives since there are plenty of good ones available. Regenerate session IDs on login, use no session IDs in URLs, HTTPOnly cookies, no XSS holes and if you're afraid of sniffing, use HTTPS. That's a pretty good defense against session hijacking and fixation. – Intranuclear

Answer 1

Encrypting won't help. The session cookie is just a magic number anyway. Encrypting it just means there's a different magic number to hijack. Depending on what hijacking scenarios you have in mind, there are other possible mitigations. For example, you can limit sessions to a single IP. That poses some issues though, e.g. people switching between wireless points.

Ivanovo

Just to (hopefully) clarify for the OP - the session in which the cookie is transferred should still be encrypted, and the cookie flag HTTPOnly should be set to prevent its transfer over unencrypted channels. Properly encrypting the communication channel over which the session cookie is transported makes it harder for an attacker to intercept the cookie. – Sylvie

The question was about encrypting the coookie itself, i.e. the value stored by the browser. I agree encrypting the traffic is worthwhile for certain applications. I think you mean the Secure flag, not (just) HTTPOnly. – Ivanovo

Thanks. This answer helped to understand the problem domain. Now I have a solution in https and where the session id is replaced for every request. – Alduino

It will prevent guessing random session ID's. – Enolaenormity

@Wout, randomly guessing an active session ID is extremely unlikely. Anyway, encrypting it doesn't help. Then, they just have to guess the correct ciphertext. – Ivanovo

Encrypting will make it harder, as there are more bits to be guessed, but on the server side not more bits have to be stored as the session ID remains the same size. So effectively encryption allows you to have somewhat smaller session ID's. – Enolaenormity

Answer 2

It's more important that your session IDs are random (that is, someone can't use their session ID to guess another person's), as the real danger is somebody getting their hands on another user's session ID. As long as you keep them truly random, there's no reason to or utility in encrypting it

Aida

Answer 3

Assuming your session cookie is a GUID, there is no point encrypting it. It would just replace one pseudo-random string with another.

Mescal

Answer 4

Make this script, access it from a web browser, then check your cookies.

<?php
  session_start();
?>

You will likely see something like this

Site         Cookie      Value
mysite.com   PHPSESSID   6fktilab3hldc5277r94qh2204

PHP does a fine job if generating a nice, unique id. There's not point in encrypting this.

Vincevincelette

This doesn't address the poster's question at all? – Buote

@zombat, I was just demonstrating that PHP doesn't generate a PHPSESSID of 5 or something completely weak like the OP was may have been thinking. – Premonish

Answer 5

Unfortunately encrypting the session ID is not going to increase security much, as the attacker can just use the encrypted form (which is the only thing visible to them anyways).

The only thing this might prevent is the trick where you send someone a link with ?PHPSESSID=foo in it, which will cause PHP to create that session. You can prevent that by using encryption and validation, but you should rather turn off session ID transfer in the URL completely.

Intranuclear

I believe just keeping session.use_trans_sid (php.net/manual/en/…) disabled is enough to prevent this. – Ivanovo

Yes, it is. Luckily it's disabled by default. – Intranuclear

Answer 6

The session ID is relatively unguessable, so that's not really the issue.

There are a things you can do related to this to counteract attacks:

• create a new session when a user signs in
• limit the length of a session

There are quite a few other things as well. I always recommend studying the Rails Guide on these issues-- it offers a very accessible explanation of known problems and countermeasures-- all equally applicable to PHP code.

Selfeducated

Answer 7

It's always a good idea to never depend on solely on one cookie or item to validate your (logged in) user(s). As mentioned above, it's a good idea to also store the IP and check with that. A good addition would be to store the USER_AGENT.

Bare in mind that if your application is open sourced, you're just as good with a session id alone because the hacker could easily identify what it is you're validating against.

Nudnik

Answer 8

It makes sense to encrypt cookie data when you use cookies to store sensitive info. that only the server should read (decrypt).

There's no reason to encrypt session id, since the hacker can use that encrypted session id to impersonate his victim.

Headforemost