Hi Andrey,
On Mon, Feb 3, 2014 at 7:54 PM, Andrey Andreev <[email protected]> wrote:
> 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.
>
Change has been done already. It does not accept uninitialized ID when
use_strict_mode=On since 5.5.
>
> 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.
>> '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.
>
If users need to use weaker settings, these users should set weaker options
by themselves. Forcing other users to use weaker setting does not make
sense to me.
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?
>> 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.
Regards,
--
Yasuo Ohgaki
[email protected]