Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:72070
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.217.176 as permitted sender)
MIME-Version: 1.0
Sender: yohgaki@gmail.com
In-Reply-To: <CAPhkiZxPZPatCKsCCih3YnOUmoUydk6MCvFjFB=AVvS-6bDYUQ@mail.gmail.com>
References: <CAPhkiZxPZPatCKsCCih3YnOUmoUydk6MCvFjFB=AVvS-6bDYUQ@mail.gmail.com>
Date: Mon, 3 Feb 2014 19:18:46 +0900
Message-ID: <CAGa2bXb1ijUNA=RNFaTDnT7JjuVjWHp1aAiFxFXbCMwQqP-GjQ@mail.gmail.com>
To: Andrey Andreev <narf@devilix.net>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=089e01493dbec296ed04f17ddbe8
Subject: Re: [PHP-DEV] [RFC] Secure Session Module Options by Default
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

--089e01493dbec296ed04f17ddbe8
Content-Type: text/plain; charset=UTF-8

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.


> '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.


> 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.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

--089e01493dbec296ed04f17ddbe8--