Re: [RFC][VOTE] Add session_create_id() function

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