Hi Michael, On Tue, Apr 12, 2016 at 5:21 PM, Michael Wallner <m...@php.net> wrote: >> 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. > > I've come to think that "unlikely" is still a bad precondition with > regards to security... :)
Yes. Almost all of crypt relies on "unlikely", though. So issue is how "unlikely" it is. I suppose almost all crypt experts agree /dev/urandom and friends are secure enough. (Except side channel attacks) >> 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. > > This RPS change is the result of just omitting hashing of the session id? and changes "session.use_strict_mode" default INI value to 1. I haven't added code to read random length from PRNG also. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
