Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:72152
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain devilix.net designates 209.85.160.178 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAGa2bXbRjDZ6j-HuOTbv7OYO8=8nNxwhqKP7kDD=8e6Hnuqs+w@mail.gmail.com>
References: <CAPhkiZxPZPatCKsCCih3YnOUmoUydk6MCvFjFB=AVvS-6bDYUQ@mail.gmail.com>
	<CAGa2bXb1ijUNA=RNFaTDnT7JjuVjWHp1aAiFxFXbCMwQqP-GjQ@mail.gmail.com>
	<CAPhkiZztkiKJQhU8ajajzUWOkbj_Hzon+8iCAVErRw=cMQGA8w@mail.gmail.com>
	<CAGa2bXbRjDZ6j-HuOTbv7OYO8=8nNxwhqKP7kDD=8e6Hnuqs+w@mail.gmail.com>
Date: Tue, 4 Feb 2014 00:29:52 +0200
Message-ID: <CAPhkiZwkdzzppBjsiFvFh7_mmWtbCKfo=OtYt-1RoB=4Kkcrzg@mail.gmail.com>
To: Yasuo Ohgaki <yohgaki@ohgaki.net>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] [RFC] Secure Session Module Options by Default
From: narf@devilix.net (Andrey Andreev)

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.