Hi Andrey,
On Tue, Feb 4, 2014 at 9:59 PM, Andrey Andreev <[email protected]> wrote:
> >> >> 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?
>
Original proposal was
session_id('SOME_USEFUL_PREFIX' . session_create_id());
and allow to set ID. New one should be
bool session_id(string $new_id_or_prefix [, bool $use_prefix=FALSE]);
(I thought I've updated the signature. It was old...)
It supposed to used like
session_id('PREFIX_', TRUE) // retunrs PREFIX_SECURE-SID
New API would not allow insecure session ID when use_strict_mode=on while
allowing user defined prefix for session ID.
>
> >> >> 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.
>
>
I have too many RFCs already...
I would like to reduce number of RFCs.
> >> 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.
To me, it's the same objective that make session usage as secure as
possible.
I don't see reason to make 2 patches/RFC for making session module secure.
Perhaps, better title would be
"Make session options/API as secure as possible"
Regarding "_" addition to files save handler, it may not be RFC issue as it
does not break anything at all. Just an simple addition of safe char that
is needed for new safe prefixed session ID with hash bits=6. It may apply
even prefixed session. I think there are many changes like this w/o RFC.
I tried to write RFC to be minimum and sufficient. I should add more
description
if it is not. Or add link of this thread. I think it's preferred way.
Regards,
--
Yasuo Ohgaki
[email protected]