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