Re: [RFC] Secure Session Module Options by Default

>> >> 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 >> > > You may be referring old RFC. Current RFC is > > Add optional $force_id parameter for session_id() to allow any id regardless > of this mode. > > bool session_id(string $new_id [, bool $force_id=FALSE]); > > This was changed as Stas(?) suggested since I agree to him. It would be more > secure > than old one. I am not referring to an old RFC, I'm saying this parameter is pointless. What difference does it make at all? How does session_id() work with and without it? >> >> 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. > > > You are ignoring the fact that there is no 'default' function that is > securely generates random bytes/ID. > > There are code that requires prefix for much efficient session data > handling. > For example, user may want to know session creation time/owner/etc > *without reading* session data. With prefixed session ID, creation > time/owner/etc > is known just selecting session ID names. For databases like PostgreSQL > which > supports function index, searching specific session is done in msec order > even > when there are millions of session IDs. I'm not ignoring anything, I'm just saying this should be in a separate RFC. >> 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. :) > > > It's new for PHP, but there are codes do this and many of them are > insecure... > I would like to eliminate insecure code by introducing easy to use API also. > > I might have chosen wrong name for the RFC. See my previous comment above. You didn't chose a wrong name, you seem to have done a 2-in-1 RFC and that's not the right approach IMO. At the very least - it's obviously confusing and most of what you've said in this conversation isn't described in the RFC at all. Cheers, Andrey.