Hi Tom, On Tue, Aug 16, 2016 at 9:08 PM, Tom Worster <f...@thefsb.org> wrote: >>> I strongly disagree with this kind of attitude. >>> >>> If there are users who really do not want collision detection at all, >>> they should do it by their own responsibility and risk. >> >>Above discussion is added to the RFC. >> >>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 theory, there wouldn't be collisions if CSPRNG is truly random that will never has collided values at any given chunks. 128 bits session ID would be far good enough. Problem is we can measure CSPRNG is producing acceptable random for apps requires randomness, but it is difficult making sure the random stream will _never_ has collision. (I'm not saying CSPRNG is not generating secure random. For most usages of random stream do not require uniqueness. Session module is special and requires collision free results for all CSPRNG.) Solution is simple for session database. All we have to do is validating newly generated session ID would not collide existing one. This is done by session module currently. Why not for new API that is supposed to generate 120% secure session ID? If users do not want 120% secure session ID, but almost 100% secure session ID is enough and would like to skip the validation. They may do if (session_ status() == PHP_SESSION_ACTIVE) session_commit(); session_id(session_create_id()); // Session is inactive, no collision check session_start(); by their own decision and risk. IMHO, other way around should not be the default. NOTE: Users will need to call session_create_id() for regenerating session ID. Therefore, there should be active session already. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
