Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:72049
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain devilix.net designates 209.85.160.175 as permitted sender)
MIME-Version: 1.0
Date: Mon, 3 Feb 2014 09:31:28 +0200
Message-ID: <CAPhkiZxPZPatCKsCCih3YnOUmoUydk6MCvFjFB=AVvS-6bDYUQ@mail.gmail.com>
To: "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,

Just sharing my initial thoughts on this ...

'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.

'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.

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?

Cheers,
Andrey.