Hi! > 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. > 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. > 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? 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. > 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. > 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. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
