RE: [PHP-DEV] Bug #13582: New Session ID's can be specified by the client.

When I realised this 'feature', and after discussions with other developers, I thought I may bring it up. Many say that they dont see why PHP should function like this, many say that they dont see why _not_ Personally I dont see why it should, and no doubt, as you mentioned, some people are (mistakenly) going to rely on it as some kind of security. Maybe I should have brought it up as a 'Feature/Change Request' Max > -----Original Message----- > From: mlwmohawk@mohawksoft.com [mailto:mlwmohawk@mohawksoft.com] > Sent: Sunday, 7 October 2001 8:57 PM > To: mfischer@guru.josefine.at > Cc: max@blueroo.net; php-dev@lists.php.net > Subject: Re: [PHP-DEV] 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 > > >