Hi Stas, On Wed, Apr 13, 2016 at 12:50 PM, Stanislav Malyshev <smalys...@gmail.com> wrote: >> 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. > > True, but is it always OK to export its state to anybody who asks, on > demand, in unlimited numbers? I'm not so sure. > >> Experts say secure PRNG like /dev/urandom is safe. > > What's "like /dev/urandom"? Each PRNG can have different properties.
Yes, but all RPNG in major OSes are supposed to be secure PRNG. > >> Why shouldn't? >> It's just a use case in the wild. > > If you want to test use case, test on real application, not on > microbenchmark. And by real application I mean one currently used, of > which none regenerate session IDs on every request, and none have > reasons to. Optimizing for narrow use case which doesn't even exist yet > against thousands of apps that already do makes no sense to me. > >> If time stamp based session management is used, there is no worries >> updating session ID on every request. > > Of course there are worries, it would generate huge traffic to session > storage which is completely unnecessary. Moreover, many application > would be broken under such model. Of course, you are free to build your > own app using such model, but it's in no way a best practice and it does > not deserve to be target of global optimization of session module for it. Users updating session ID always do not concern disabling lazy_write, I suppose. >> 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) > > We can't claim both PRNG are secure and PRNG aren't secure. So which is it? When we discussed about randam_*() functions, links to pages are posted. > > In any case, I don't see how this mandates turning on strict sessions. I > know you want it to be the default, but it doesn't seem to be related to > this topic. Probability of collision is close to zero, but it's not zero unless it is validated. It's a precaution for broken PRNG on new OSes, too. It's closely related to me, different point of view. > >> There is no BC. >> Removed INI are just ignored if users are used. > > But users used them for something. If that something doesn't happen, > then it's broken. INI setting is always worked this way. I don't see problem ignoring settings e.g. register_globals=on, magic_quote_gpc=on > >> Question is "Current session ID is generation is optimal way?" or "Is it >> better than proposed one?" If so, why? > > Yes, it's better - it does not export PRNG state needlessly, and it's > already proven to work by thousands of applications. I'm OK with adding > a non-hashed option, for people that want to try it out, and eventually > if everybody ends up using it and nothing bad happens, we could phase > out the hashed ones then. But just dropping them out of the blue and > making non-hashed the only option does not look like a good solution. > >> 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? > > We should not invent our own PRNG. Hashing it though seems like a > reasonable precaution. If we have to hide PRNG state, skipping random bytes would do the job. This is much simpler and faster. We cannot say current implementation is better. SSL/TLS removed multiple use of hashes because it could be weaker. Use of additional hashing does not necessary a good thing as distribution of hashed value (session ID) is biased by hash algorithm. Only 32 bytes are read from PRNG by default. Therefore, it's close to direct exposure even with hash. We probably should discuss php_random_bytes() if it is considered as crypto secure or not. If yes, we may simply rely on it. (My discussion is based on this) If not, we need to improve php_random_bytes() implementation. Regards, P.S. Another reason why I would like to remove hashing is availability of stronger hashes. Hash extension can be disabled, thus there should be fallback code. It's not clean. Stronger hashes are slower also. -- Yasuo Ohgaki yohg...@ohgaki.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
