Hi Tom, On Sun, Aug 14, 2016 at 12:22 AM, Tom Worster <f...@thefsb.org> wrote: > 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.
Generally speaking, you should consider "=" padding when you use Base64 encoding. Refer to https://tools.ietf.org/html/rfc4648#section-8 and relevant sections. > > >>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. My point of view is "session" (the connection/request state management) should "just work" without knowing details. My recent session related proposals accomplish this objective. IMO. PHP should be easiest, yet secure, Web application programming language. I don't see any benefits, but only drawbacks, forcing users "to know session management details to write secure code" while it is very easy to implement tham in Session module. > > >>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. No. It means we should be careful about CSPRNG randomness. Therefore, I validate SID. > > >>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. I'm reading between the line here. Cryptographers considers hash less 256 bits is not longer secure. They think 256 bits or more to avoid collisions. As you may know, CSPRNGs use hashes internally. This fact makes me think we shouldn't blindly trust CSPRNG return values less than 256bits. > > > >>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. If you would like to know how many bits (true random bits) required for secure session ID. Following link is helpful to figure out some aspect of session ID security. https://www.owasp.org/index.php/Insufficient_Session-ID_Length We use 130bits out of CSPRNG radam for PHP 7.1. How many bytes is required for secure session ID is depends on CSPRNG quality and measuring CSPRNG quality is difficult. To avoid collision, all we have to do is validating SID then problem is solved. (Predictability is different issue) > >>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. Even serious cryptographers admits difficulty of CSPRNG quality assurance. We cannot force OSes to have excellent CSPRNG that will never have collision for obtained bytes. > > >>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. My proposal is much secure than your proposal. It is clear by logic described above that my proposal is more secure. Anyway, if things can done easily by PHP, if it is related to security and if users can forget about secureness when they stick to normal PHP usage, PHP should be provided as default feature. Let user mustn't know session security details! I think this is the way PHP should go. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
