Hi Stas, On Wed, Apr 13, 2016 at 1:12 AM, Stanislav Malyshev <smalys...@gmail.com> 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. > > That assumes we use /dev/urandom directly and it is always available on > all systems and always accessible to PHP. I don't think it is the case > now, is it?
Yes and no. Patch uses php_random_bytes(), so it uses appropriate PRNG for the system. php_random_bytes() is supposed to be available always. > >> 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) > > We have pretty good way of removing this problem. It's called hashing. > Now we are inventing our own crypto tricks to not use existing and > proven method of doing it. This looks like bad idea to me. We do not > have expertise to even evaluate if it's safe. Experts say secure PRNG like /dev/urandom is safe. >> 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) > > My point is it does not matter. Nobody cares if session ID generation > takes 1 ms instead of 2 ms. > >> 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. > > No they won't. Even if they change session ID on every request (which > sounds extremely weird, I have never seen anybody doing it and would > never recommend doing it) the different would still be unnoticeable if > the application does anything beyond generating session IDs. Unless you > can show speedup on real apps, I don't think this point is worth ever > mentioning again. Why shouldn't? It's just a use case in the wild. The reason why regenerating session ID always is not recommended is because there is no "Time Stamp" based management in current session which is declined recently. If time stamp based session management is used, there is no worries updating session ID on every request. >> We cannot control PRNG behavior. It's enabled for broken PRNG >> insurance. use_strict_mode=1 (detecting session ID collisions) is >> mandatory, anyway. > > If we are assuming broken PRNG, it surely is unsafe to export its state > to the whole world. Either we assume PRNG is safe and sound, or not. And > I really don't like the idea of grouping unrelated changes together. Discussion is based on FUD. AFAIK, I saw papers state PRNGs are secure enough, but opposite. (We can safely ignore side channel attack issue, I suppose) > >> has comment for keeping hash/PRNG related INIs? I would like to remove >> hash/PRNG related INIs if not many of us insist. > > I think removing existing INI entries is completely unnecessary and just > creates BC problems without any benefit. There is no BC. Removed INI are just ignored if users are used. Security concern is endless. We need to trust something, otherwise endless mitigation is required. Modern secure PRNGs are good enough to rely on just like other security related features like hash, encryption, etc. Simple mitigation like reading random length from PRNG should be good enough for those who are concerned secure RPNG vulnerability. Question is "Current session ID is generation is optimal way?" or "Is it better than proposed one?" If so, why? Crypto experts say "secure PRNG is safe", why should we care too much about secure PRNG vulnerability? Why we should invent our own entropy added random value and take hash of it? Regards, -- Yasuo Ohgaki yohg...@ohgaki.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
