Beefy Boxes and Bandwidth Generously Provided by pair Networks
We don't bite newbies here... much

Re^3: Identifying clients

by Thelonius (Priest)
on Dec 06, 2006 at 21:02 UTC ( [id://588188]=note: print w/replies, xml ) Need Help??

in reply to Re^2: Identifying clients
in thread Identifying clients

I make my session IDs 64 bits long. Even if they could check 1 million/sec, it would still take more than 5000 years before they could have even a 1% chance of finding one.

Replies are listed 'Best First'.
Re^4: Identifying clients
by ruzam (Curate) on Dec 06, 2006 at 21:31 UTC
    Well, my session id is suitably big enough, and random (or as random as the random function makes it). And you're absolutely right about the length of time needed to roll through them all. Maybe that's enough?
      I think the Session ID should be based on multiple time-dependant sureties and not a random value as there is a possibility, however small or unpredictable, that two calls to rand() might return the same value. If a session is based on time, surely it makes sense to use a time-dependant value in choosing a session ID.

      As to how big a session ID string should be, well big enough to ensure that there are no session-ID collisions within the lifetime of your application. A SHA1 hash of a few values quite surely suffices but might not be ideal due to the overhead required in calculating the hash. Maybe some other hashing algorithm that is less-resource intensive?

      perl -e '$,=$",$_=(split/\W/,$^X)[y[eval]]]+--$_],print+just,another,split,hack'er

        That sounds like a good idea. The overhead need not be too great, as you only do it when creating a new session. For the fake attempts, you only need to compare it with the valid session IDs.


        My choice of code for this is:

        $session = substr(crypt(rand(),'XX'),2);

        Which creates a tidy 13 character (printable) string with no fuss or muss. The session is used to create a MySQL table entry (where the session field is a unique primary key). There's a loop to keep generating session ids if the row insert fails due to a duplicate key. I could throw a time element into it, but I don't think this would buy any improvement.

        I suppose there are also ways to defeat the not so random nature of 'rand()', but I'll leave that to the DOD ;).

        Assuming a 13 char string is sufficient variation to (reasonably) prevent a session attack.

Log In?

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

How do I use this?Last hourOther CB clients
Other Users?
Others contemplating the Monastery: (2)
As of 2024-06-22 03:00 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.