Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:72075
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain devilix.net designates 209.85.160.173 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAGa2bXb1ijUNA=RNFaTDnT7JjuVjWHp1aAiFxFXbCMwQqP-GjQ@mail.gmail.com>
References: <CAPhkiZxPZPatCKsCCih3YnOUmoUydk6MCvFjFB=AVvS-6bDYUQ@mail.gmail.com>
	<CAGa2bXb1ijUNA=RNFaTDnT7JjuVjWHp1aAiFxFXbCMwQqP-GjQ@mail.gmail.com>
Date: Mon, 3 Feb 2014 12:54:01 +0200
Message-ID: <CAPhkiZztkiKJQhU8ajajzUWOkbj_Hzon+8iCAVErRw=cMQGA8w@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)

Hi,

On Mon, Feb 3, 2014 at 12:18 PM, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote:
> Hi Andrey,
>
> On Mon, Feb 3, 2014 at 4:31 PM, Andrey Andreev <narf@devilix.net> 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.