Re: Bug #13582: New Session ID's can be specified by the client.

Sorry to jump in here, but I have a real problem with developers thinking that session ID is somehow secure. It isn't. srand ((double) microtime() * 1000000); $new_id = md5(rand()); session_id($new_id); The above code, in particular, is completely bogus. On x86 machines, the resolution of "msec" in microtime() is quite limited. Seeding repeatedly with a number of limited scope circumvents any benefits of the random generator. (I pointed this out to Stig, and he changed the srand() documentation.) The md5() call adds nothing to the quality of the random number. The session_ID generated from the above code would probably have a good number of collisions on an active site. (i.e. multiple people would get the same session ID at login.) Here is a test you can check for yourself: <? $array = array(); for($i=0; $i < 50000; $i++) { srand ((double) microtime() * 1000000); $new_id = md5(rand()); $array[$i] = $new_id; } sort($array); $dups=0; for($i=1; $i < 50000; $i++) { if($array[$i-1] == $array[$i]) $dups++; } echo $dups . " duplicate sessions <br>\n"; ?> This brings me to the real point, I wrote an extension, msession, that is intended to handle a lot of session issues. I am in the middle of updating the docs to talk about security, and thought I should mention some of the key points. You should never EVER use the session ID as a form of security. Any number which can be generated by a computer can probably be cracked. Also random numbers are not guaranteed to be unique and uniqueness is a vital piece of security. If security is an issue, you must use information in addition to a session ID. The IP address of the caller and/or some function of their password, perhaps their user name as well. You have to use stuff that is harder to figure out, and the combination of which will be unique. > I guess I'm missing something here. > > It is _not true_ if you have already accessed the page. Ie, you > can't change the session id afterwards. > > If the page is accessed the _first_ time this, then is true. > > IMO it's the responsibility of the developer to ensure that the > ID is actually valid one. There are many ways of doing this. > > - Markus > > On Sun, Oct 07, 2001 at 04:40:52AM -0000, max@blueroo.net wrote : >> From: max@blueroo.net >> Operating system: Both Linux & Windows >> PHP version: 4.0.4pl1 >> PHP Bug Type: Session related >> Bug description: New Session ID's can be specified by the client. >> >> PHP allows a client to specify what its SID will be by passing a >> Cookie, GET, or POST variable to a script, with the same session name >> as the script uses. >> >> An example script: >> >> <? >> session_name('id'); >> session_start(); >> print 'In ' . phpversion() . ', your session ID is: ' . session_id(); >> ?> >> >> If the above script is accessed via >> http://www.example.com/test.php?id=blehbleh >> >> This will print "In 4.0.x, your session ID is: blehbleh" >> >> (Tested in php 4.0.4pl1 & 4.0.6) >> >> After discussions with several people, we were unable to find any >> reason why the client should be able to specify what its SID should >> be, unless a session with that SID has been started. >> >> IMHO, If a session with the provided SID has not been started, the >> server should generate an ID and give it to the client, instead of the >> accepting the client specified SID. >> >> A workaround is to add the following code: >> >> srand ((double) microtime() * 1000000); >> $new_id = md5(rand()); >> session_id($new_id); >> >> >> ...after session_name() and before session_start(), on a page that >> will re initialiase/destroy a session, such as a login or logout page. >> >> With this workaround (and/or a fix) it is possible to create login >> scripts which are more secure. ie a script that does not send plain >> text passwords, and does not transmit the same encrypted details on >> consecutive logins. >> >> Although I have provided a workaround, i thought it should be >> mentioned, (or fixed within the codebase itsself) >> >> Please excuse me if I am missing something, and this is actually a >> feature. >> >> Regards, >> >> Max Holman >> >> PS: I will be releasing a script to demonstrate the (more) secure >> login, if you are interested, please email me (note that it requires >> Javascript on the client side) >> -- >> Edit bug report at: >> http://bugs.php.net/?id=13582&edit=1 >> >> >> -- >> PHP Development Mailing List <http://www.php.net/> >> To unsubscribe, e-mail: php-dev-unsubscribe@lists.php.net >> For additional commands, e-mail: php-dev-help@lists.php.net >> To contact the list administrators, e-mail: >> php-list-admin@lists.php.net > > -- > Markus Fischer, http://guru.josefine.at/~mfischer/ > EMail: mfischer@guru.josefine.at > PGP Public Key: http://guru.josefine.at/~mfischer/C2272BD0.asc > PGP Fingerprint: D3B0 DD4F E12B F911 3CE1 C2B5 D674 B445 C227 2BD0 > -All your scripts are belong to Zend- > > -- > PHP Development Mailing List <http://www.php.net/> > To unsubscribe, e-mail: php-dev-unsubscribe@lists.php.net > For additional commands, e-mail: php-dev-help@lists.php.net > To contact the list administrators, e-mail: > php-list-admin@lists.php.net