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.