Hi Stas, On Fri, Apr 8, 2016 at 8:36 AM, Stanislav Malyshev <smalys...@gmail.com> wrote: >> Session module does not require hashing to generate session ID. This >> RFC removes hashing from session module and enable use_strict_mode as >> an insurance for broken RNG. >> >> https://wiki.php.net/rfc/session-id-without-hashing > > I'm not sure why that should be the default. First of all, I'm not sure > exporting the state of the PRNG is that good an idea, there may be > vulnerability in the PRNG that could be opened (or made easier) for > exploit with direct access to its output. I'd rather not provide this > opening unnecessarily.
PRNG like /dev/urandom is supposed to be secure, but fair point. It may be good idea keeping old hash based session ID just in case someone find vulnerability. I suppose it's unlikely with modern PRNGs, though. If we have to care about PRNG state exposure, code may be changed to read random length from RPNG. This would be good enough mitigation. I would like to hear from PRNG experts if this is good enough. (or not needed) >Second, I do not see why we need to do maximum > breakage change if we could just make an identity "hash" function and > support both cases. "Session generation performance" does not have a lot > of meaning here - I'd be very surprised to see any application that is > bound by the speed of generating session IDs. w/ Patch: Requests per second: 2278.59 [#/sec] (mean) w/o Patch: Requests per second: 899.36 [#/sec] (mean) (This is CLI server and "ab -c 20 -n 100000" result on Core i7 4770s Linux) I didn't expect this much difference, but this is the result. Since security experts advise to change session ID relatively high frequency (few minutes to half an hour), this difference may be noticeable apps returning cached JSON. I know apps that change session ID on every request. (This should be done with caution. Otherwise, you may experience lost sessions a lot due to race conditions) Such apps will see performance gain. > Also, I don't see how use_strict_mode change is related to the hashing. > Could you explain? We cannot control PRNG behavior. It's enabled for broken PRNG insurance. use_strict_mode=1 (detecting session ID collisions) is mandatory, anyway. Regards, P.S. Code may be changed so that user can choose raw PRNG and old hashing. We have to keep old and new INI settings in this case. Anyone has comment for keeping hash/PRNG related INIs? I would like to remove hash/PRNG related INIs if not many of us insist. -- Yasuo Ohgaki yohg...@ohgaki.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
