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? | [reply] |
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] |
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] |
| [reply] |
