Re: [RFC] Secure Session Module Options by Default

Hey, >> I was just pointing out that 'use_strict_mode' shouldn't change the >> behavior of session_id(). >> In other words, you don't need a "force" option, because passing a >> custom made ID by itself already tells it to force something. > > > Change has been done already. It does not accept uninitialized ID when > use_strict_mode=On since 5.5. I know that. I'm saying it should work like you suggested without the need of another option. session_id(<user input>); // changes session ID to the user-supplied string, regardless of use_strict_mode >> Don't know why you're talking about prefixes here ... nothing to do >> with security. > > > I see many codes that uses insecure session ID. The main reason why > they write such bad code is 'lack of secure ID generation feature'. > > It's security matter, IMHO. Why is that necessary at all? session_regenerate_id() not sufficient? Either way, this shouldn't be a part of this RFC. It's your RFC, but still - it's about changing default settings for improved security, not new features. >> Not that I have any authority around here, but I'd recommend updating >> the RFC to properly explain this. As it stands, it makes it almost >> makes it look like incrementing the 'hash_bits_per_character' value by >> itself increases security, and it doesn't. :) > > > It does not improve security, but it reduces session ID length changed by > this RFC. Are you suggesting another RFC for changing > hash_bits_per_character? > Or are you suggesting I should change the default without a RFC? We've obviously got a language barrier here. All I'm suggesting is that you improve the *wording* in your RFC, so that it is clear why hash_bits_per_character is changed. >> >> That "allow an underscore when hash_bits_per_character=6" is also not >> >> in the scope of security and the hash function itself wouldn't >> >> generate an underscore, so ... what has it got to do with anything? >> > >> > >> > If hash_bits_per_character=6, files save handler uses all chars for >> > session >> > ID and users cannot have prefix delimiter char. User may use string >> > offset, >> > though. That's the reason why there is '_' proposal. >> >> This is hard to follow, I really don't understand why we're talking >> about prefixing here at all and how does it relate to >> 'hash_bits_per_character' or security. > > > To improve security, I proposed larger hash and hash bits to decrease number > of chars. I know there are users that use prefix and delimiter. Why > shouldn't I > address these affected users in the same RFC? > > This security related changes may affect users and if it does, we should > provide > work round for it at the same time if it is feasible. IMHO. Because, as I said above - I thought this RFC was about changing default settings and nothing else. And again, an underscore *is not* a part of the hash, regardless of hash_bits_per_character. I personally don't care about the prefix. It's just that it's a completely new feature that has nothing to do with the default settings and it's just confusing that you mention it in the same context. :) Cheers, Andrey.