unique session id

[princepawn]

I have seen Apache::Session, but am wondering just how long I can be sure that the session id's it generates will be valid To me, it seems that incremental generation of ids is more failsafe than those long strings it generates.

[httptech]

Incremental generation of ids is not very secure, because a user could easily hijack someone else's session just by bumping his/her session id up or down.

I've also seen security problems with random session ids, though. For example, the WebX message board system, a popular commercial BBS. It uses some very funky session IDs to track logins. However, it also allows limited HTML, including hyperlinks. So, all I need to do is add a hyperlink into my message that leads to a CGI script on a server I control. The CGI script reads the HTTP_REFERER info, and forwards it to me via email. Now I have that user's session ID, and if I get there before their session times out, I can hijack their session and forge messages, mess with configuration settings, etc.

Just things to consider when you are going to be using session IDs.

[DrManhattan]

That's a good point. Just generating a random session id isn't enough. You also have to make sure you aren't getting a session id from a client other than the one you issued it to.

There was a really interesting thread about securing session ids on the mod_perl mailing list a couple of months ago.

The trick is that you need to store some validation information such as the client's ip address or a session timeout along with the session key. That way you can verify (or at least be more certain) that the client presenting the session key to you is the correct one.

There are basically two schools of thought: You can either encrypt the extra information in the session key itself, or you can store in it a database indexed by the session key. Each method has its advatanges. The first requires some processing overhead to decrypt the data stored in the session key and possibly more bandwidth since the session keys may be longer. The second requires a database hit each time you verify the key. It's essentially a CPU vs. IO tradeoff.

Here's a link to the thread: http://forum.swarthmore.edu/epigone/modperl/jytwortwor/[e-mail]

- Matt

[gregorovius]

The newer version of Apache::Session has 32 byte session id strings. I don't know if these are randomly generated or if the algorithm takes care of verifying that they're not repeated, but given the number of bits involved I would say that the chance of it generating the same key twice (for a human population) is smaller than 1/(number of hydrogen atoms in the universe). :-)

[PipTigger]

I wrote some code to do something similar last week. It doesn't check the $HTTP_REFERER or anything but it's not a Message Board system either so there's not a significant likelihood that a generated seshunid is going to be hijacked or even visible by anyone but the logged in user. It's more like a hidden tag which indexes a server-side cookie for transaction state information. In hindsight, I'd change the time stuff to be all seconds like time() instead of the array context of localtime() but it werks now so I'll change it later if I get around to it. I'm putting the code in craft... Here it is! I hope someone finds it mildly useful. Feel free to email me with any questions or more likely suggestions on how I could do it better (I have much to lern!). TTFN & Shalom.

-PipTigger

p.s. Byslexia is a Ditch!