Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:89025
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain thefsb.org designates 173.203.187.91 as permitted sender)
To: Leigh <leight@gmail.com>, internals@lists.php.net
References: <CAPwsocFbM1wYzNni_M02Vd4m4giVeH36RH8uhWfC-uk_uaSqNw@mail.gmail.com>
Message-ID: <563638C6.3010304@thefsb.org>
Date: Sun, 1 Nov 2015 11:07:34 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0)
 Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <CAPwsocFbM1wYzNni_M02Vd4m4giVeH36RH8uhWfC-uk_uaSqNw@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: Make sessions use php_random_bytes in 7.1
From: fsb@thefsb.org (Tom Worster)

On 10/30/15 3:48 PM, Leigh wrote:
> Hi all,
>
> I would like to refactor session id generation to use our new
> php_random_bytes API as the single entropy source for session ids,
> targeting 7.1
>
> Overall this would give a small performance increase to session generation,
> a large security increase to session generation, and remove some points of
> possible user error.
>
> There are a few things to consider while doing this:
>
> session.entropy_file will no longer needed, as the best source of random
> for the operating system will be selected.
>
> session.entropy_length should be ignored, as this was to specify the length
> of *additional* entropy, and may be non-zero in legacy configuration files,
> that are preserved across upgrades
>
> session.hash_function should be deprecated, there is no benefit to hashing
> cryptographically strong random bytes, however people may be relying on
> this to get session ids of a certain length.
>
> We will have to introduce a new setting to control session id length,
> perhaps overridden if session.hash_function is non-default. We have a year
> to play with the details.
>
> I'd like to hear if there are any strong objections to this proposal.

I don't have one.

But if I may ask, I'm curious, as always: What happens in the case that 
php_random_bytes() fails?

Tom