Hi Yasu, On 8/12/16, 4:38 PM, "Yasuo Ohgaki" <yohg...@ohgaki.net> wrote:
>Base 64 adds padding for extra bytes. The Padding char is "=" and it's >illegal char as SID. Therefore trims is mandatory. substr(base64_encode(random_bytes($n)), 0, $n). There is no "=" in the value for any $n. >Don't you think it's nice to make "PHP just works" without knowing such >details? Not in this particular instance, no. Anybody that takes on the responsibility of designing a scheme for session ID generation needs to know such details. The typical PHP programmer does/should not do such work because its is difficult and dangerous and because the requirement seldom arises. PHP should not try to patch up garbage session IDs by rejecting IDs already in use. >Session ID security is key factor of Web application security. There >is huge difference between 'cannot happen' and 'very rare and almost >cannot happen'. In addition, proving 'very rare and almost cannot >happen' is difficult. This is equivalent to saying that random_bytes() cannot be trusted as a CSPRNG. >NIST requires SHA2 or better hash for collision sensitive usage. SHA2 >has 256 bits or more. We only use 128 bits, i.e. MD5 and >bits_per_character=5 now. (130 bits for 7.1 and later). Hashing is not the same problem. It's different in some important ways. >Therefore, I >don't think collision check is needless. We should have 256 bits >session ID at least which requires 52 chars with 5 bits_per_character. I don't think NIST's hashing recommendations should be the basis for saying how many random bits PHP session IDs should have. I think we should make our own calculations from first principles. >We know it's relatively easy to check if a PRNG meets NIST >requirement, but requirement fulfillment does not mean PRNG is >generating excellent random. Measuring quality of PRNG is difficult. >(This does not mean we should add low quality entropy such as time and >pid to create SID and hash it. We depends on PRNG security anyway, use >of hash and low quality entropy only makes SID weaker. Thus I proposed >raw PRNG usage for SID) Since 7.0, PHP uses the best available practices to obtain random bytes from the operating system's CSPRNG. These practices are generally considered good enough for strong cryptography, which demands as much from a CSPRNG as PHP sessions. It doesn't make sense to distrust random_bytes() but at the same time trust the host PHP runs on. >These things make me think collision detection is mandatory to say >"PHP session is secure". > >Anyway, I'm not a cryptographer and just following their advices. I >suggest you do the same. I don't agree with the conclusions you draw from NIST hashing recommendations. Tom -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
