Hi,
On Mon, Feb 3, 2014 at 12:18 PM, Yasuo Ohgaki <[email protected]> wrote:
> Hi Andrey,
>
> On Mon, Feb 3, 2014 at 4:31 PM, Andrey Andreev <[email protected]> wrote:
>>
>> 'use_strict_mode' is supposed to generate a new session ID when the
>> application receives a session cookie with an invalid (non-existing)
>> session ID.
>> I don't think that it should've ever changed the behavior of
>> session_id() and I'd rather consider it a bug if it doesn't allow it
>> to set the new session ID.
>
>
> I can understand your opinion. Yet, it would be better for users to have
> securely prefixed session ID. IMHO.
>
> string session_id('PREFIX_', TRUE);
>
> This does not set insecure session ID, since it only adds prefix to
> generated session ID.
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.
Don't know why you're talking about prefixes here ... nothing to do
with security.
>> 'hash_bits_per_character' has nothing to do with security and its only
>> useful purpose that I could think of is maintainig BC for
>> database-stored session data, where i.e. the ID used to be an md5 hash
>> and and switching to sha1 would require altering the field length to
>> 40. Increasing hash_bit_per_character in that case would allow a
>> sha-1-sized hash to be stored in 32 characters.
>> Other than that (and probably some crazy traffic volume-related
>> micro-optimization), it's pretty useless.
>
>
> Since the RFC is proposing stronger hash function as NIST suggests,
> session ID needs to have longer hash bits. To reduce size of session ID,
> larger hash bits is proposed. Similar reason you explained.
>
> Some user may have limited storage size for session ID. However, it's
> not a good excuse keeping weaker setting. Users need weaker settings
> should set values for their own. IMHO.
I'm not sure I understand what you're saying.
If it is that you want to maintain BC on the session ID length - sure,
I see how that would be nice to have.
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. :)
>> 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.
Cheers,
Andrey.