On 8/16/16 10:51 AM, Lester Caine wrote:
On 16/08/16 13:08, Tom Worster wrote:
The default 128 bits Session ID is large enough to ignore collisions
https://wiki.php.net/rfc/session-create-id#discussions
It describes for an application, but PHP is a platform.
There are millions PHP apps or more and there could be billions of
active sessions. There could be tens of thousands new session IDs or
more are created. Apply the calculation for expected time of possible
collision.
Do you still sure "There will be no collisions at all"?
The calculation underestimates the difficulty of finding collisions by 38
decimal orders of magnitude. The number of different SIDs in default PHP
config is 2^192, not 2^64. So yes, I am still sure.
In a distributed system which would be required to handle millions of
sessions at the same time, then one will have thousands of copies of PHP
running and shared via some sort of traffic manager. So unless some sort
of mechanism is included to provide identification of the PHP instance
then it is probable that different instances will all produce the same
sequence of numbers. A UUID generator provided to ensure every
distributed service has a uniquely identifiable id for every 'session'
is not something that forms part of a single instance of PHP. It must be
centrally managed with a central session store. All that a single
instance of PHP should be worrying about is a few hundred active sessions?
(I think you could use a hash for this. But that's beside the point
because...)
I have no problem with session_create_id().
I have a problem with saying that CSPRNG is so untrustworthy that users
must find ways to compensate for its faults in their code.
And I have a problem with a statement to this effect being in the RFC.
And with that statement obscuring the crux of the argument with
misleading math about an SID database.
Tom
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
