On 08/04/16 04:17, Yasuo Ohgaki 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... :) > > 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? -- Regards, Mike
signature.asc
Description: OpenPGP digital signature
