Re: [RFC][DISCUSSION] Session ID without hashing

From: Date: Tue, 12 Apr 2016 11:01:14 +0000
Subject: Re: [RFC][DISCUSSION] Session ID without hashing
References: 1 2 3 4  Groups: php.internals 
Request: Send a blank email to internals+get-92217@lists.php.net to get a copy of this message
Hi Michael, On Tue, Apr 12, 2016 at 5:21 PM, Michael Wallner <mike@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 yohgaki@ohgaki.net

« previous php.internals (#92217) next »