Beefy Boxes and Bandwidth Generously Provided by pair Networks
Just another Perl shrine

unique session id

by princepawn (Parson)
on Jun 08, 2000 at 18:27 UTC ( [id://17084]=perlquestion: print w/replies, xml ) Need Help??

princepawn has asked for the wisdom of the Perl Monks concerning the following question:

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.

Replies are listed 'Best First'.
Re: unique session id
by httptech (Chaplain) on Jun 08, 2000 at 18:55 UTC
    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.

      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:

      - Matt
Re: unique session id
by gregorovius (Friar) on Jun 08, 2000 at 20:00 UTC
    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). :-)
RE: unique session id
by PipTigger (Hermit) on Jun 09, 2000 at 00:41 UTC
    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.


    p.s. Byslexia is a Ditch!

Log In?

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlquestion [id://17084]
Approved by root
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others taking refuge in the Monastery: (3)
As of 2024-07-21 16:14 GMT
Find Nodes?
    Voting Booth?

    No recent polls found

    erzuuli‥ 🛈The London Perl and Raku Workshop takes place on 26th Oct 2024. If your company depends on Perl, please consider sponsoring and/or attending.