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

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?

Replies are listed 'Best First'.
Re^5: Identifying clients
by Firefly258 (Beadle) on Dec 07, 2006 at 05:17 UTC
    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
[reply]
[d/l]
[select]
      Firefly258:

      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.

      --roboticus

[reply]
      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.
[reply]
        Consider this :- 
        my $session1 = crypt rand, 'XX';
my $session2 = crypt rand, 'AA';

        [download]
        Are you always guaranteed to have different values for $session1 and $session2?? No, there is an incalculable chance that they might be same.

        I would consider a function of some non-random values instead, something along the lines of this. 
        my $session - crypt time, "XX";

        [download]
        But two clients could still end up with the same session ID, so here's a to try and guarantee that no two session IDs are ever the same, even in the oddest case where the same user has logged in at multiple instances. 
        my $rawID = time . ( toNum( $userID ) % toNum( $password ) +
            toNum( $ENV{REMOTE_ADDR} ) % $ENV{REMOTE_PORT} );

my $sessionID = crypt $rawID, "PY";

        [download]
        It's still imperfect, but you can always amend it to your needs. Also, I'm not sure how seriously crypt() can be taken as a trustworthy hashing function.


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

In Section Seekers of Perl Wisdom