[PHP-DEV] Re: [RFC][VOTE] Session ID without hashing - Vote reopened and restarted

[Yasuo Ohgaki]

Hi Christoph,

On Tue, Aug 9, 2016 at 12:44 AM, Christoph M. Becker  wrote:
>
> I've just noticed that the voting is still open, although it's already
> 2016-08-08.  Shouldn't it be closed?

Thank you!
Closed.

--
Yasuo Ohgaki
yohg...@ohgaki.net

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: [RFC][VOTE] Session ID without hashing - Vote reopened and restarted

[Christoph M. Becker]

Hi Yasuo!

On 25.07.2016 at 11:49, Yasuo Ohgaki wrote:

> Due to defects in the RFC, vote is reopened and restarted.
> Followings are changes from 1st vote.
>
> […]
>
> Vote ends 2016/08/02 23:59:59 UTC.

I've just noticed that the voting is still open, although it's already
2016-08-08.  Shouldn't it be closed?

-- 
Christoph M. Becker

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: [RFC][VOTE] Session ID without hashing - Vote reopened and restarted

[Yasuo Ohgaki]

Hi all and Davey,

On Wed, Aug 3, 2016 at 4:36 PM, Davey Shafik  wrote:
>
> Unfortunately this missed beta2 (tagged yesterday), I'll confirm with Joe
> about putting it in for 7.1beta3.
>
> Thanks for those last minute changes, I'm much happier with this result! :)

I just realized, php.ini-development/production uses

session.hash_func=0
session.hash_bits_per_character=5 (Compiled default is 4)

The session ID will be ^[0-9a-v]{26}$ (length=26 chars)

So I'll modify php.ini-* default to
session.sid_length=26
session.sid_bit_per_character=5

This matches the current default session ID format used widely. Sorry
for the confusions, but compatible should mean compatible with current
default.

Regards,

P.S. Davery, should I push the patch to 7.1 and master branch, or you will?
I don't mind pasting the patch for 7.1 branch to gist.

--
Yasuo Ohgaki
yohg...@ohgaki.net

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: [RFC][VOTE] Session ID without hashing - Vote reopened and restarted

[Davey Shafik]

Hey Yasuo,

Unfortunately this missed beta2 (tagged yesterday), I'll confirm with Joe
about putting it in for 7.1beta3.

Thanks for those last minute changes, I'm much happier with this result! :)

- Davey

On Tue, Aug 2, 2016 at 10:29 PM, Yasuo Ohgaki  wrote:

> Hi all,
>
> Session ID without hashing
> https://wiki.php.net/rfc/session-id-without-hashing#vote
>
> This RFC is passed 9 vs 0.
> Compatible default is used as default. 7 vs 3.
>
> It needs to update the default INI. I'll finish it in a few days.
>
> Thank you for voting!
> --
> Yasuo Ohgaki
> yohg...@ohgaki.net
>
>
> On Mon, Jul 25, 2016 at 6:49 PM, Yasuo Ohgaki  wrote:
> > Hi all,
> >
> > Due to defects in the RFC, vote is reopened and restarted.
> > Followings are changes from 1st vote.
> >
> >  - Removed session.use_strict_mode change
> >(Changed when vote reopened)
> >  - Added INI default vote options, incompatible and compatible.
> >(Changed when 2nd vote is restarted)
> >  - Extended vote period for 2 days.
> >
> > These who are voted already have to **VOTE AGAIN**.
> > Sorry for the inconvenience and confusion!
> >
> > 
> >
> > Currently session module uses obsolete MD5 for session ID. With
> > CSPRNG, hashing is redundant and needless. It adds hash module
> > dependency and inefficient.
> >
> > This proposal cleans up session code by removing hash.
> >
> > https://wiki.php.net/rfc/session-id-without-hashing
> >
> > I set vote requires 2/3 support.
> > Please describe the reason why when you against this RFC. Reasons are
> > important for improvements!
> >
> > Vote ends 2016/08/02 23:59:59 UTC.
> >
> > Thank you for voting!
> >
> > --
> > Yasuo Ohgaki
> > yohg...@ohgaki.net
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>

[PHP-DEV] Re: [RFC][VOTE] Session ID without hashing - Vote reopened and restarted

[Yasuo Ohgaki]

Hi all,

Session ID without hashing
https://wiki.php.net/rfc/session-id-without-hashing#vote

This RFC is passed 9 vs 0.
Compatible default is used as default. 7 vs 3.

It needs to update the default INI. I'll finish it in a few days.

Thank you for voting!
--
Yasuo Ohgaki
yohg...@ohgaki.net


On Mon, Jul 25, 2016 at 6:49 PM, Yasuo Ohgaki  wrote:
> Hi all,
>
> Due to defects in the RFC, vote is reopened and restarted.
> Followings are changes from 1st vote.
>
>  - Removed session.use_strict_mode change
>(Changed when vote reopened)
>  - Added INI default vote options, incompatible and compatible.
>(Changed when 2nd vote is restarted)
>  - Extended vote period for 2 days.
>
> These who are voted already have to **VOTE AGAIN**.
> Sorry for the inconvenience and confusion!
>
> 
>
> Currently session module uses obsolete MD5 for session ID. With
> CSPRNG, hashing is redundant and needless. It adds hash module
> dependency and inefficient.
>
> This proposal cleans up session code by removing hash.
>
> https://wiki.php.net/rfc/session-id-without-hashing
>
> I set vote requires 2/3 support.
> Please describe the reason why when you against this RFC. Reasons are
> important for improvements!
>
> Vote ends 2016/08/02 23:59:59 UTC.
>
> Thank you for voting!
>
> --
> Yasuo Ohgaki
> yohg...@ohgaki.net

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: [RFC][VOTE] Session ID without hashing - Reopened

[Yasuo Ohgaki]

Hi all,

Old votes are removed. Everyone already have voted 1st vote should vote again!

https://wiki.php.net/rfc/session-id-without-hashing#vote

Sorry for the inconvenience & thank you for voting!

--
Yasuo Ohgaki
yohg...@ohgaki.net


On Sun, Jul 24, 2016 at 1:50 PM, Yasuo Ohgaki  wrote:
> Hi all,
>
> Due to a defect in the RFC, vote is reopened for a week. Removed lines
> are indicated by . No additional lines nor modifications
> other than removed lines for session.use_strict_mode change.
> Sorry for the confusion!
>
> 
>
> Currently session module uses obsolete MD5 for session ID. With
> CSPRNG, hashing is redundant and needless. It adds hash module
> dependency and inefficient (There is no reason to use hash for CSPRNG
> generated bytes).
>
> This proposal cleans up session code by removing hash.
>
> https://wiki.php.net/rfc/session-id-without-hashing
>
> I set vote requires 2/3 support.
> Please describe the reason why when you against this RFC. Reasons are
> important for improvements!
>
> Thank you!
>
> --
> Yasuo Ohgaki
> yohg...@ohgaki.net

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: [RFC][VOTE] Session ID without hashing

[Pierre Joye]

Hi Yasuo,

On Jul 24, 2016 10:51 AM, "Yasuo Ohgaki"  wrote:
>
> Hi all,
>
> On Sun, Jul 24, 2016 at 6:13 AM, Stanislav Malyshev 
wrote:
> >> Changing the RFC during voting requires a _restart_ not an extension.
> >> The vote must be re-run. I will not put this in 7.1 without a new vote.
> >
> > OK, looks like I was underestimating the magnitude of the messiness that
> > this change (or lack of it) brought to a vote. Let's re-run the vote
> > then, I think that would be the best solution given the confusion that
> > apparently happened.
>
> I'll open reopen the vote a week.
> Is this too long?
>

No it is not. Sadly I did not follow up on that when I said the vote should
start again.

The idea of a minimum voting period is not an option but a must. We
introduced it in the relase process rfc, as well as the minimum discussion
time, to be sure everyone has a chance to voice out and vote.

We have been a bit too tolerant lately  (like "as this is a small change I
only setup one week discussion"). This must not happen. It is not about the
content of a rfc but the time available for contributors to act. And all
contributors do not follow the RFCs daily.

Cheers
Pierre

Re: [PHP-DEV] Re: [RFC][VOTE] Session ID without hashing

[Yasuo Ohgaki]

Hi all,

On Sun, Jul 24, 2016 at 6:13 AM, Stanislav Malyshev  wrote:
>> Changing the RFC during voting requires a _restart_ not an extension.
>> The vote must be re-run. I will not put this in 7.1 without a new vote.
>
> OK, looks like I was underestimating the magnitude of the messiness that
> this change (or lack of it) brought to a vote. Let's re-run the vote
> then, I think that would be the best solution given the confusion that
> apparently happened.

I'll open reopen the vote a week.
Is this too long?

Regards,

--
Yasuo Ohgaki
yohg...@ohgaki.net

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: [RFC][VOTE] Session ID without hashing

[Stanislav Malyshev]

Hi!

> Changing the RFC during voting requires a _restart_ not an extension.
> The vote must be re-run. I will not put this in 7.1 without a new vote.

OK, looks like I was underestimating the magnitude of the messiness that
this change (or lack of it) brought to a vote. Let's re-run the vote
then, I think that would be the best solution given the confusion that
apparently happened.

-- 
Stas Malyshev
smalys...@gmail.com

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: [RFC][VOTE] Session ID without hashing

[Davey Shafik]

Stas,

The issue is that changes were made once the voting started, and some of us
were waiting for the vote to restart:

> I'd like to see the vote re-run (1 week?) with the changes in place. I
didn't vote because I expected it to be restarted. I would have voted -1 on
the current proposal.

Changing the RFC during voting requires a _restart_ not an extension. The
vote must be re-run. I will not put this in 7.1 without a new vote.

- Davey

On Sat, Jul 23, 2016 at 12:50 PM, Stanislav Malyshev 
wrote:

> Hi!
>
> > We already had a vote, at it was completed. Having another vote on the
> > same subject, slightly modified, is highly irregular and contrary to
> > voting RFC, which mandates 6 month period or *substantial* changes (with
> > assumed new discussion period I imagine, since past discussion can't
> > really count for substantially changed proposal) to schedule a new vote
> > on a rejected proposal.
> >
> > This also gives pretty bad example - on failed vote, tweak a little
> > issue and issue immediate revote, repeat until one of the votes
> > succeeds. I understand that this is not at all your intent here, but
> > it's the pattern that we do not want to enable.
> >
> > I voted yes for it, and it is a pity that it failed, as it seems,
> > because of a miscommunication (maybe not, I don't know), but going
> > against our own agreed process I think is not a good outcome either.
>
> Oops, I thought I was talking about another RFC vote that failed. Sorry
> for the confusion. This one seems to have succeeded. This is weirder
> case then... I'd say just implement the uncontroversial part then and
> submit the controversial part as a new RFC?
>
> --
> Stas Malyshev
> smalys...@gmail.com
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>

Re: [PHP-DEV] Re: [RFC][VOTE] Session ID without hashing

[Stanislav Malyshev]

Hi!

> We already had a vote, at it was completed. Having another vote on the
> same subject, slightly modified, is highly irregular and contrary to
> voting RFC, which mandates 6 month period or *substantial* changes (with
> assumed new discussion period I imagine, since past discussion can't
> really count for substantially changed proposal) to schedule a new vote
> on a rejected proposal.
> 
> This also gives pretty bad example - on failed vote, tweak a little
> issue and issue immediate revote, repeat until one of the votes
> succeeds. I understand that this is not at all your intent here, but
> it's the pattern that we do not want to enable.
> 
> I voted yes for it, and it is a pity that it failed, as it seems,
> because of a miscommunication (maybe not, I don't know), but going
> against our own agreed process I think is not a good outcome either.

Oops, I thought I was talking about another RFC vote that failed. Sorry
for the confusion. This one seems to have succeeded. This is weirder
case then... I'd say just implement the uncontroversial part then and
submit the controversial part as a new RFC?

-- 
Stas Malyshev
smalys...@gmail.com

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: [RFC][VOTE] Session ID without hashing

[Stanislav Malyshev]

Hi!

> I missed to remove the related lines in RFC. I marked the line by .
> I don't mind reopen the vote few days. Any objections?
> If no objections, I'll reopen vote few days.

We already had a vote, at it was completed. Having another vote on the
same subject, slightly modified, is highly irregular and contrary to
voting RFC, which mandates 6 month period or *substantial* changes (with
assumed new discussion period I imagine, since past discussion can't
really count for substantially changed proposal) to schedule a new vote
on a rejected proposal.

This also gives pretty bad example - on failed vote, tweak a little
issue and issue immediate revote, repeat until one of the votes
succeeds. I understand that this is not at all your intent here, but
it's the pattern that we do not want to enable.

I voted yes for it, and it is a pity that it failed, as it seems,
because of a miscommunication (maybe not, I don't know), but going
against our own agreed process I think is not a good outcome either.
-- 
Stas Malyshev
smalys...@gmail.com

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: [RFC][VOTE] Session ID without hashing

[Yasuo Ohgaki]

Hi Derick,

On Tue, Jul 12, 2016 at 7:25 PM, Derick Rethans  wrote:
> The voted-upon-RFC still has
>
>> session.use_strict_mode (0 to 1) - Changed as insurance of broken PRNG 
>> implementation.
>
> Although you said:
>
> It was moved to other RFC.
>
> https://wiki.php.net/rfc/session-use-strict-mode
>
> And neither did you restart voting after modifying the RFC - or writing
> down in the RFC's changes that it got changed.
>
> So what's the deal?

I missed to remove the related lines in RFC. I marked the line by .
I don't mind reopen the vote few days. Any objections?
If no objections, I'll reopen vote few days.

Regards,

--
Yasuo Ohgaki
yohg...@ohgaki.net

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: [RFC][VOTE] Session ID without hashing

[Yasuo Ohgaki]

Hi all and RM,

On Sat, Jul 2, 2016 at 4:35 PM, Yasuo Ohgaki  wrote:
> Currently session module uses obsolete MD5 for session ID. With
> CSPRNG, hashing is redundant and needless. It adds hash module
> dependency and inefficient (There is no reason to use hash for CSPRNG
> generated bytes).
>
> This proposal cleans up session code by removing hash.
>
> https://wiki.php.net/rfc/session-id-without-hashing
>
> I set vote requires 2/3 support.
> Please describe the reason why when you against this RFC. Reasons are
> important for improvements!

The changes in the manual is committed. UPGRADING is written, PR
branch is synced for merge.

https://github.com/php/php-src/pull/1850

Should I merge or just telling "please merge" is OK?

Regards,

--
Yasuo Ohgaki
yohg...@ohgaki.net

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: [RFC][VOTE] Session ID without hashing

[Yasuo Ohgaki]

Hi Davey,

On Wed, Jul 13, 2016 at 6:59 AM, Davey Shafik  wrote:
> On Tue, Jul 12, 2016 at 3:25 AM, Derick Rethans  wrote:
>>
>> Hi,
>>
>> The voted-upon-RFC still has
>>
>> > session.use_strict_mode (0 to 1) - Changed as insurance of broken
>> > PRNG implementation.
>>
>> Although you said:
>>
>> It was moved to other RFC.
>>
>> https://wiki.php.net/rfc/session-use-strict-mode
>>
>> And neither did you restart voting after modifying the RFC - or writing
>> down in the RFC's changes that it got changed.
>>
>> So what's the deal?
>
>
> I'd like to see the vote re-run (1 week?) with the changes in place. I
> didn't vote because I expected it to be restarted. I would have voted -1 on
> the current proposal.
>
> Also, is it possible to add a notice/warning if any of the removed config
> settings are set to a non-default value?
>
> We should also have the defaults be the same as for older versions of PHP,
> otherwise it's a BC break. That is:
>
> session.sid_length=32
> session.sid_bits_per_character=4
>
> Better settings should be documented and in the default ini files, but not
> be changed till 8.0 IMO.
>
> I apologize for this feedback being so late.

Thank you for the comment!

I think it's not good idea to change the default from now.
I'll document compatibility issue well in UPGRADING.

Regards,

--
Yasuo Ohgaki
yohg...@ohgaki.net

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: [RFC][VOTE] Session ID without hashing

[Yasuo Ohgaki]

Hi Derick,

On Tue, Jul 12, 2016 at 7:25 PM, Derick Rethans  wrote:
> Hi,
>
> The voted-upon-RFC still has
>
>> session.use_strict_mode (0 to 1) - Changed as insurance of broken PRNG 
>> implementation.
>
> Although you said:
>
> It was moved to other RFC.
>
> https://wiki.php.net/rfc/session-use-strict-mode
>
> And neither did you restart voting after modifying the RFC - or writing
> down in the RFC's changes that it got changed.
>
> So what's the deal?

session.use_strict_mode change in the patch is included by mistake.

Someone pointed it out immediately after starting vote, RFC does not refer
use_strice_mode change. I removed the change and extended vote period
a day.

RFC itself does not change (It didn't mention use_strict_mode change at all)
and I didn't get any comments on this, but now I got one.

Any suggestions?
Re-opening vote few days or a week is fine with me.

Regards,

--
Yasuo Ohgaki
yohg...@ohgaki.net

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: [RFC][VOTE] Session ID without hashing

[Davey Shafik]

On Tue, Jul 12, 2016 at 3:25 AM, Derick Rethans  wrote:

> Hi,
>
> The voted-upon-RFC still has
>
> > session.use_strict_mode (0 to 1) - Changed as insurance of broken
> PRNG implementation.
>
> Although you said:
>
> It was moved to other RFC.
>
> https://wiki.php.net/rfc/session-use-strict-mode
>
> And neither did you restart voting after modifying the RFC - or writing
> down in the RFC's changes that it got changed.
>
> So what's the deal?
>

I'd like to see the vote re-run (1 week?) with the changes in place. I
didn't vote because I expected it to be restarted. I would have voted -1 on
the current proposal.

Also, is it possible to add a notice/warning if any of the removed config
settings are set to a non-default value?

We should also have the defaults be the same as for older versions of PHP,
otherwise it's a BC break. That is:

session.sid_length=32
session.sid_bits_per_character=4

Better settings should be documented and in the default ini files, but not
be changed till 8.0 IMO.

I apologize for this feedback being so late.

Thanks,

- Davey

Re: [PHP-DEV] Re: [RFC][VOTE] Session ID without hashing

[Derick Rethans]

Hi,

The voted-upon-RFC still has 

> session.use_strict_mode (0 to 1) - Changed as insurance of broken PRNG 
> implementation.

Although you said:

It was moved to other RFC.

https://wiki.php.net/rfc/session-use-strict-mode

And neither did you restart voting after modifying the RFC - or writing 
down in the RFC's changes that it got changed.

So what's the deal?

cheers,
Derick




On Tue, 12 Jul 2016, Yasuo Ohgaki wrote:

> Hi all,
> 
> On Sat, Jul 2, 2016 at 4:35 PM, Yasuo Ohgaki  wrote:
> > Currently session module uses obsolete MD5 for session ID. With
> > CSPRNG, hashing is redundant and needless. It adds hash module
> > dependency and inefficient (There is no reason to use hash for CSPRNG
> > generated bytes).
> >
> > This proposal cleans up session code by removing hash.
> >
> > https://wiki.php.net/rfc/session-id-without-hashing
> >
> > I set vote requires 2/3 support.
> > Please describe the reason why when you against this RFC. Reasons are
> > important for improvements!
> >
> > Thank you!
> 
> Thank you for voting and the RFC has passed 13 vs 5.
> I'll prepare documents and merge the change in a few days.
> 
> Regards,
> 
> --
> Yasuo Ohgaki
> yohg...@ohgaki.net
> 
> 

-- 
https://derickrethans.nl | https://xdebug.org | https://dram.io
Like Xdebug? Consider a donation: https://xdebug.org/donate.php
twitter: @derickr and @xdebug

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: [RFC][VOTE] Session ID without hashing

[Yasuo Ohgaki]

Hi all,

On Sat, Jul 2, 2016 at 4:35 PM, Yasuo Ohgaki  wrote:
> Currently session module uses obsolete MD5 for session ID. With
> CSPRNG, hashing is redundant and needless. It adds hash module
> dependency and inefficient (There is no reason to use hash for CSPRNG
> generated bytes).
>
> This proposal cleans up session code by removing hash.
>
> https://wiki.php.net/rfc/session-id-without-hashing
>
> I set vote requires 2/3 support.
> Please describe the reason why when you against this RFC. Reasons are
> important for improvements!
>
> Thank you!

Thank you for voting and the RFC has passed 13 vs 5.
I'll prepare documents and merge the change in a few days.

Regards,

--
Yasuo Ohgaki
yohg...@ohgaki.net

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: [RFC][VOTE] Session ID without hashing

[Leigh]

On 7 July 2016 at 21:33, Dan Ackroyd  wrote:
>> I think we need to drop the concerns about exposing "RNG state".
>>
>> If these are weak RNGs on your system, YOUR SYSTEM is broken.
>
> Telling people that their system is broken isn't going to be
> comforting to the people it happens to.

Of course it isn't. If I find out suddenly that /dev/urandom is
somehow predictable I would be incredibly uncomfortable. However the
least of my worries would be PHPs session id generation.

> There are always bugs in software and hardware. At some point it is
> almost inevitable that there will be some information leak through
> exposing the random numbers directly. Just telling people that their
> system is broken and they need to buy need hardware immediately,
> rather than just being able to re-enable hashing seems a bad choice.

I feel like we're back to the discussions around random_bytes() again.

The random number generators being used here are designated CS for a
reason. They are not like deterministic RNGs where you can give them
simple seed and produce the same set of outputs. They draw on
environmental noise for additional entropy and where appropriate they
reseed regularly, far before any useful statistical information can be
gathered.

In the case of urandom it actually performs a SHA1 on its pool,
CryptGenRandom mixes in data that has been MD4 hashed, arc4random_buf
is literally a stream cipher. These are well maintained and vetted
systems. An extra round of hashing is simply unnecessary overhead.

> But even without accidental bugs, the scenario I am remain concerned
> with is when a piece of hardware or software is compromised by a
> sophisticated attacker, (hello NSA!) and the 'random' numbers
> generated have some subtle pattern to them. To almost everyone, the
> random numbers generated would still look random. But to the
> organisation that compromised the system, and so knows the algorithm
> that is leaving traces in the random sequences, exposing the random
> numbers directly to the outside world would be an obvious but almost
> untraceable line of attack on the system.

I know it's easy to say: If your system has been compromised you have
bigger problems. But this is pretty much the fact of it. If someone
has the ability to make your system CSPRNG predictable, they can
almost certainly get anything else they want from the system anyway
without resorting to that.

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: [RFC][VOTE] Session ID without hashing

[Niklas Keller]

>
> > I think we need to drop the concerns about exposing "RNG state".
> >
> > If these are weak RNGs on your system, YOUR SYSTEM is broken.
>
> Telling people that their system is broken isn't going to be
> comforting to the people it happens to.
>

Sure, but it's the right way. Just like random_bytes having no fallback.

There are always bugs in software and hardware. At some point it is
> almost inevitable that there will be some information leak through
> exposing the random numbers directly. Just telling people that their
> system is broken and they need to buy need hardware immediately,
> rather than just being able to re-enable hashing seems a bad choice.
>

Nobody talks about buying new hardware. It usually happens due to bad
system setup, such as blocking access to /dev/random.

But even without accidental bugs, the scenario I am remain concerned
> with is when a piece of hardware or software is compromised by a
> sophisticated attacker, (hello NSA!) and the 'random' numbers
> generated have some subtle pattern to them. To almost everyone, the
> random numbers generated would still look random. But to the
> organisation that compromised the system, and so knows the algorithm
> that is leaving traces in the random sequences, exposing the random
> numbers directly to the outside world would be an obvious but almost
> untraceable line of attack on the system.
>
> Hashing should still obfuscate any subtle patterns in the random
> number generation, and so give some protection against comprised
> chip-set/firmware. If users choose to continue to want the extra
> security of hashing, at the cost of slightly slower session ID
> generation we shouldn't removed that from them.
>
> Yasuo wrote:
> > Some of us worried about CSPRNG state exposure. I'm wondering how many
> > of you will vote in favor if I change the RFC to use hash functions
> > optionally.
>
> Yes.
>
> Though as I said before, I think changing session.use_strict_mode
> should be a separate decision, and it's one I support doing.
>
> cheers
> Dan
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] Re: [RFC][VOTE] Session ID without hashing

[Yasuo Ohgaki]

Hi Dan,

On Fri, Jul 8, 2016 at 5:33 AM, Dan Ackroyd  wrote:
>> I think we need to drop the concerns about exposing "RNG state".
>>
>> If these are weak RNGs on your system, YOUR SYSTEM is broken.
>
> Telling people that their system is broken isn't going to be
> comforting to the people it happens to.
>
> There are always bugs in software and hardware. At some point it is
> almost inevitable that there will be some information leak through
> exposing the random numbers directly. Just telling people that their
> system is broken and they need to buy need hardware immediately,
> rather than just being able to re-enable hashing seems a bad choice.
>
> But even without accidental bugs, the scenario I am remain concerned
> with is when a piece of hardware or software is compromised by a
> sophisticated attacker, (hello NSA!) and the 'random' numbers
> generated have some subtle pattern to them. To almost everyone, the
> random numbers generated would still look random. But to the
> organisation that compromised the system, and so knows the algorithm
> that is leaving traces in the random sequences, exposing the random
> numbers directly to the outside world would be an obvious but almost
> untraceable line of attack on the system.
>
> Hashing should still obfuscate any subtle patterns in the random
> number generation, and so give some protection against comprised
> chip-set/firmware. If users choose to continue to want the extra
> security of hashing, at the cost of slightly slower session ID
> generation we shouldn't removed that from them.

I understand concern and I would not argue against that hashing should
still obfuscate PRNG state.

The patch proposed/session module has mitigations
 - Read extra bytes from RPNG to hide raw PRNG state
  (This should be good enough mitigation for usable CSPRNG)
 - In case PRNG generates the same session IDs repeatedly, it
terminate execution with E_ERROR/E_RECOVERABLE_ERROR.
  (This shouldn't happen with good CSPRNG)

Above mitigations should be good enough for CSRPNG applications.
System with seriously broken CSPRNG should not be used anyway. IMO.

Vote requires 2/3 in favor. Current vote is 6 vs 3.
If this RFC declined, I'll prepare patch that has optional hashing.

Regards,

--
Yasuo Ohgaki
yohg...@ohgaki.net

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: [RFC][VOTE] Session ID without hashing

[Yasuo Ohgaki]

Hi Leigh,

On Thu, Jul 7, 2016 at 5:25 PM, Leigh  wrote:
> On 6 July 2016 at 22:30, Yasuo Ohgaki  wrote:
>> php_session_create_id() may return NULL. It's an usual error. Session
>> module supports session ID creation save handler which may return
>> anything valid for the type.
>>
>> Session module tries to call php_session_create_id() several
>> places/times. If it could not get valid one, it raises
>> E_RECOVERABLE_ERROR or E_ERROR eventually.
>>
>> Although it's not enabled yet, PHP_FUNCTION(session_create_id) returns
>> FALSE it fails.
>
> If it fails due to a lack of random, it throws a fatal. Tested your PR
> and forced the fd of /dev/urandom to -1 in ext/standard/random.c
>
> $ sapi/cli/php -n -r 'session_start();'
>
> Next Exception: Cannot open source device in Command line code:1
> Stack trace:
> #0 Command line code(1): session_start()
> #1 {main}
>   thrown in Command line code on line 1
>
> Fatal error: session_start(): Failed to create session ID: files
> (path: ) in Command line code on line 1

session_start() will result in E_ERROR or E_RECOVERABLE_ERROR
currently. I've tried to change E_ERROR to E_RECOVERABLE_ERROR before,
but it was reverted because someone objected.

session_create_id() which is disabled by #define returns FALSE now. I
need RFC vote to enable session_create_id(). It was added as FR
implementation, but it is disabled for the same reason above.

There are many places need cleanup.

Regards,

--
Yasuo Ohgaki
yohg...@ohgaki.net

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: [RFC][VOTE] Session ID without hashing

[Dan Ackroyd]

> I think we need to drop the concerns about exposing "RNG state".
>
> If these are weak RNGs on your system, YOUR SYSTEM is broken.

Telling people that their system is broken isn't going to be
comforting to the people it happens to.

There are always bugs in software and hardware. At some point it is
almost inevitable that there will be some information leak through
exposing the random numbers directly. Just telling people that their
system is broken and they need to buy need hardware immediately,
rather than just being able to re-enable hashing seems a bad choice.

But even without accidental bugs, the scenario I am remain concerned
with is when a piece of hardware or software is compromised by a
sophisticated attacker, (hello NSA!) and the 'random' numbers
generated have some subtle pattern to them. To almost everyone, the
random numbers generated would still look random. But to the
organisation that compromised the system, and so knows the algorithm
that is leaving traces in the random sequences, exposing the random
numbers directly to the outside world would be an obvious but almost
untraceable line of attack on the system.

Hashing should still obfuscate any subtle patterns in the random
number generation, and so give some protection against comprised
chip-set/firmware. If users choose to continue to want the extra
security of hashing, at the cost of slightly slower session ID
generation we shouldn't removed that from them.

Yasuo wrote:
> Some of us worried about CSPRNG state exposure. I'm wondering how many
> of you will vote in favor if I change the RFC to use hash functions
> optionally.

Yes.

Though as I said before, I think changing session.use_strict_mode
should be a separate decision, and it's one I support doing.

cheers
Dan

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: [RFC][VOTE] Session ID without hashing

[Christoph Becker]

On 06.07.2016 at 23:30, Yasuo Ohgaki wrote:
>
> On Wed, Jul 6, 2016 at 9:10 PM, Christoph Becker  wrote:
>>
>> Yes, I am aware that the patch uses php_random_bytes(), but what happens
>> when it fails, in which case php_session_create_id() returns null[1]?
>> Would it be impossible to use a session in this case?
> 
> php_session_create_id() may return NULL. It's an usual error. Session
> module supports session ID creation save handler which may return
> anything valid for the type.
> 
> Session module tries to call php_session_create_id() several
> places/times. If it could not get valid one, it raises
> E_RECOVERABLE_ERROR or E_ERROR eventually.
> 
> Although it's not enabled yet, PHP_FUNCTION(session_create_id) returns
> FALSE it fails.

Thanks for the explanation, Yasuo.  AIUI, the old session module would
not fail on such (most likely rare) occasions, however.  If that is so,
I suggest to note that in the "Backward Incompatible Changes" section of
the RFC (so that it would be noted in UPGRADING and the migration guide).

-- 
Christoph M. Becker


-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: [RFC][VOTE] Session ID without hashing

[Leigh]

On 6 July 2016 at 22:30, Yasuo Ohgaki  wrote:
> php_session_create_id() may return NULL. It's an usual error. Session
> module supports session ID creation save handler which may return
> anything valid for the type.
>
> Session module tries to call php_session_create_id() several
> places/times. If it could not get valid one, it raises
> E_RECOVERABLE_ERROR or E_ERROR eventually.
>
> Although it's not enabled yet, PHP_FUNCTION(session_create_id) returns
> FALSE it fails.

If it fails due to a lack of random, it throws a fatal. Tested your PR
and forced the fd of /dev/urandom to -1 in ext/standard/random.c

$ sapi/cli/php -n -r 'session_start();'

Next Exception: Cannot open source device in Command line code:1
Stack trace:
#0 Command line code(1): session_start()
#1 {main}
  thrown in Command line code on line 1

Fatal error: session_start(): Failed to create session ID: files
(path: ) in Command line code on line 1

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: [RFC][VOTE] Session ID without hashing

[Yasuo Ohgaki]

Hi Christoph,

On Wed, Jul 6, 2016 at 9:10 PM, Christoph Becker  wrote:
>
> Yes, I am aware that the patch uses php_random_bytes(), but what happens
> when it fails, in which case php_session_create_id() returns null[1]?
> Would it be impossible to use a session in this case?

php_session_create_id() may return NULL. It's an usual error. Session
module supports session ID creation save handler which may return
anything valid for the type.

Session module tries to call php_session_create_id() several
places/times. If it could not get valid one, it raises
E_RECOVERABLE_ERROR or E_ERROR eventually.

Although it's not enabled yet, PHP_FUNCTION(session_create_id) returns
FALSE it fails.

Regards,

--
Yasuo Ohgaki
yohg...@ohgaki.net

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: [RFC][VOTE] Session ID without hashing

[Leigh]

On Wed, 6 Jul 2016 at 13:10 Christoph Becker  wrote:

>
> Yes, I am aware that the patch uses php_random_bytes(), but what happens
> when it fails, in which case php_session_create_id() returns null[1]?
> Would it be impossible to use a session in this case?
>
> [1]
> <
> https://github.com/php/php-src/pull/1850/files#diff-52eb9eb7f9d5d9125fbb1337a6541c06R315
> >
>
> --
> Christoph M. Becker
>

The FAILURE check here is redundant because it is using the _throw variant
of random_bytes, which means an exception is thrown if there isn't a good
source of random available.

Re: [PHP-DEV] Re: [RFC][VOTE] Session ID without hashing

[Christoph Becker]

Hi Yasuo!

On 06.07.2016 at 03:51, Yasuo Ohgaki wrote:
>
> On Wed, Jul 6, 2016 at 12:37 AM, Christoph Becker  wrote:
>> On 05.07.2016 at 16:32, Leigh wrote:
>>
>>> On 5 July 2016 at 04:02, Pierre Joye  wrote:
 We can argue about the provided pnrng being CS but it is not php's job to
 decide.
>>>
>>> I think we need to drop the concerns about exposing "RNG state".
>>>
>>> A reminder of what php_random_bytes looks at (in order):
>>> * CryptGenRandom on Windows
>>> * arc4random_buf on modern BSD (where ChaCha20 is used)
>>> * Linux getrandom(2) syscall where available
>>> * /dev/urandom where available
>>> * Throws an exception if it cannot access one of the above
>>
>> Would that imply that in this latter case sessions couldn't be used
>> anymore?  What would be the fallback in that case?  From a quick glance
>> at the current PR there appears to be none!
> 
> It relies on php_random_bytes() defined in ext/standard/random.c
> Current PHP does not build without decent PRNG. The patch uses
> php_random_bytes() simply.

Yes, I am aware that the patch uses php_random_bytes(), but what happens
when it fails, in which case php_session_create_id() returns null[1]?
Would it be impossible to use a session in this case?

[1]


-- 
Christoph M. Becker

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: [RFC][VOTE] Session ID without hashing

[Yasuo Ohgaki]

Hi Christoph,

On Wed, Jul 6, 2016 at 12:37 AM, Christoph Becker  wrote:
> On 05.07.2016 at 16:32, Leigh wrote:
>
>> On 5 July 2016 at 04:02, Pierre Joye  wrote:
>>> We can argue about the provided pnrng being CS but it is not php's job to
>>> decide.
>>
>> I think we need to drop the concerns about exposing "RNG state".
>>
>> A reminder of what php_random_bytes looks at (in order):
>> * CryptGenRandom on Windows
>> * arc4random_buf on modern BSD (where ChaCha20 is used)
>> * Linux getrandom(2) syscall where available
>> * /dev/urandom where available
>> * Throws an exception if it cannot access one of the above
>
> Would that imply that in this latter case sessions couldn't be used
> anymore?  What would be the fallback in that case?  From a quick glance
> at the current PR there appears to be none!

It relies on php_random_bytes() defined in ext/standard/random.c
Current PHP does not build without decent PRNG. The patch uses
php_random_bytes() simply.

Regards,

--
Yasuo Ohgaki
yohg...@ohgaki.net

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: [RFC][VOTE] Session ID without hashing

[Stanislav Malyshev]

Hi!

> Some of us worried about CSPRNG state exposure. I'm wondering how many
> of you will vote in favor if I change the RFC to use hash functions
> optionally. This means code and INI settings related to hash function
> selection will remain. Please note that ext/hash is not built always.
> If you against keeping hash related code, please let me know also.

Re-reading RFC, I'd also propose this:

- Make session.sid_bits_per_character take value from
session.hash_bits_per_character if the latter is defined and the former
is not
- Remove use_strict_mode change, it is a different issue.

With this, and possibility of keeping hash as non-default option, I'd be
for this RFC.
-- 
Stas Malyshev
smalys...@gmail.com

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: [RFC][VOTE] Session ID without hashing

[Stanislav Malyshev]

Hi!

> Some of us worried about CSPRNG state exposure. I'm wondering how many
> of you will vote in favor if I change the RFC to use hash functions
> optionally. This means code and INI settings related to hash function
> selection will remain. Please note that ext/hash is not built always.
> If you against keeping hash related code, please let me know also.

If there would be an option to not use hash, I would be completely fine
with it.

-- 
Stas Malyshev
smalys...@gmail.com

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: [RFC][VOTE] Session ID without hashing

[Tom Worster]

On 7/5/16 11:37 AM, Christoph Becker wrote:

On 05.07.2016 at 16:32, Leigh wrote:


On 5 July 2016 at 04:02, Pierre Joye  wrote:

We can argue about the provided pnrng being CS but it is not php's job to
decide.


I think we need to drop the concerns about exposing "RNG state".

A reminder of what php_random_bytes looks at (in order):
* CryptGenRandom on Windows
* arc4random_buf on modern BSD (where ChaCha20 is used)
* Linux getrandom(2) syscall where available
* /dev/urandom where available
* Throws an exception if it cannot access one of the above


Would that imply that in this latter case sessions couldn't be used
anymore?


I hope so.

It's not safe to use sessions if PHP cannot get unpredictable randoms 
for session IDs. PHP should therefore error so that the sys op can be 
alerted and fix the problem.


Tom



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: [RFC][VOTE] Session ID without hashing

[Christoph Becker]

On 05.07.2016 at 16:32, Leigh wrote:

> On 5 July 2016 at 04:02, Pierre Joye  wrote:
>> We can argue about the provided pnrng being CS but it is not php's job to
>> decide.
> 
> I think we need to drop the concerns about exposing "RNG state".
> 
> A reminder of what php_random_bytes looks at (in order):
> * CryptGenRandom on Windows
> * arc4random_buf on modern BSD (where ChaCha20 is used)
> * Linux getrandom(2) syscall where available
> * /dev/urandom where available
> * Throws an exception if it cannot access one of the above

Would that imply that in this latter case sessions couldn't be used
anymore?  What would be the fallback in that case?  From a quick glance
at the current PR there appears to be none!

-- 
Christoph M. Becker

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: [RFC][VOTE] Session ID without hashing

[Leigh]

On 5 July 2016 at 04:02, Pierre Joye  wrote:
> We can argue about the provided pnrng being CS but it is not php's job to
> decide.

I think we need to drop the concerns about exposing "RNG state".

A reminder of what php_random_bytes looks at (in order):
* CryptGenRandom on Windows
* arc4random_buf on modern BSD (where ChaCha20 is used)
* Linux getrandom(2) syscall where available
* /dev/urandom where available
* Throws an exception if it cannot access one of the above

If these are weak RNGs on your system, YOUR SYSTEM is broken. They are
all designed to be cryptographic quality.

If people are unconvinced we can temper the values with a secondary
RNG, but there is absolutely no need to generate session IDs using a
slow hashing algorithm.

For the record, I am +1 on removing hashing, -1 on the _other_ changes
in this RFC

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: [RFC][VOTE] Session ID without hashing

[Yasuo Ohgaki]

Hi all,

On Sat, Jul 2, 2016 at 4:35 PM, Yasuo Ohgaki  wrote:
> Currently session module uses obsolete MD5 for session ID. With
> CSPRNG, hashing is redundant and needless. It adds hash module
> dependency and inefficient (There is no reason to use hash for CSPRNG
> generated bytes).
>
> This proposal cleans up session code by removing hash.
>
> https://wiki.php.net/rfc/session-id-without-hashing
>
> I set vote requires 2/3 support.
> Please describe the reason why when you against this RFC. Reasons are
> important for improvements!
>
> Thank you!

Some of us worried about CSPRNG state exposure. I'm wondering how many
of you will vote in favor if I change the RFC to use hash functions
optionally. This means code and INI settings related to hash function
selection will remain. Please note that ext/hash is not built always.
If you against keeping hash related code, please let me know also.

Thank you!

--
Yasuo Ohgaki
yohg...@ohgaki.net

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: [RFC][VOTE] Session ID without hashing

[Yasuo Ohgaki]

Hi Pierre,

On Tue, Jul 5, 2016 at 12:02 PM, Pierre Joye  wrote:
>> Current implementation is regenerating random hash string by using
>>
>>  - PID
>>  - Time (Simple random function)
>>  - CSPRNG when it is available
>
> For clarification, it is always available. Php requires a valid one to be
> built.
>
> We can argue about the provided pnrng being CS but it is not php's job to
> decide.

Thank you for clarification!
Modern systems that execute PHP should have CSPRNG always.

Regards,

--
Yasuo Ohgaki
yohg...@ohgaki.net

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: [RFC][VOTE] Session ID without hashing

[Pierre Joye]

On Jul 5, 2016 6:14 AM, "Yasuo Ohgaki"  wrote:
>
> Hi Stas,
>
> Thank you for sharing opinion.
> Followings is mine.
>
> On Tue, Jul 5, 2016 at 7:23 AM, Stanislav Malyshev 
wrote:
> >> Could you share the reason why against this change?
> >
> > 1. I'm not sure exporting raw generator state is a good practice. I may
> > change my opinion on the subject if I hear from some security people
> > (I'm no crypto expert) that this is ok, then I may change my opinion.
>
> I think no one can guarantee security of CSPRNG on all platforms.
>
> "CS" means cryptographic safety and cryptographers recommends
> not to reinvent crypt related functions/features.
>
> > 2. Due to (1), I do not think it makes sense to do this change, because
> > we produce no benefit (session generation speed is not that important
> > since nobody generates millions of sessions at once) and create
> > potential problems.
>
> Current implementation is regenerating random hash string by using
>
>  - PID
>  - Time (Simple random function)
>  - CSPRNG when it is available

For clarification, it is always available. Php requires a valid one to be
built.

We can argue about the provided pnrng being CS but it is not php's job to
decide.

[PHP-DEV] Re: [RFC][VOTE] Session ID without hashing

[Yasuo Ohgaki]

Hi Dan,

On Tue, Jul 5, 2016 at 9:36 AM, Dan Ackroyd  wrote:
>> Could you share the reason why against this change?
>
> The RFC is doing separate things:

No.
It simply follows best practice not to reinvent wheel and keep things simple.

>
> * Using a proper random number generator - which is probably a good
> thing, and I probably would vote/support that change by itself.

Use of not a really random values like pid and time is bad practice.

>
> * Removing old stuff for performance reasons - probably a bad thing,
> as minor performance improvements don't justify changing the ini
> settings imo.

It's not an objective, but side effect improvement.

>
> * Slipping in a change to make 'session.use_strict_mode' be enbled by
> default. I actually agree with this change, but I don't like how it's
> been combined into an unrelated RFC.

There is a request for inclusion, but I made separate RFC.

Besides that making separate RFCs for this kind of simple mandatory
change does not make much sense. I have too many RFCs already. I
created RFC for it, though.

> * Exposing information that could be useful to an attacker, from the RFC:

I don't understand this part.

>
>> If PRNG has vulnerability that generates predictable value, exposing
>> raw PRNG state helps attackers. Although, this is unlikely with modern 
>> PRNGs, but
>> risk is there.
>
> I don't agree that faster session generation is worth exposing the
> random number generator in a completely known way to the outside
> world. Reading an extra 60 bytes almost certainly does nothing to
> mitigate that exposure.

Don't miss the basis of this RFC. It's not PRNG, but CSPRNG.
Exposure of raw CSPRNG should not be a security issue at all by CSPRNG
definition. Additional random data that read from CSPRNG should be good
enough mitigation.

>
>> cryptographers recommends
>> not to reinvent crypt related functions/features.
>
> They also recommend reducing your attack surface as much as possible,
> not opening it up to the point where you're relying on the CSPRNG to
> work perfectly to avoid having a security hole.

Use of poor random sources like pid and time is bad practice.

Old SSL used multiple hashes to mitigate hash functions'
vulnerabilities, but this method is not used today for reason.

>
> But more importantly, as I wrote before
> (http://news.php.net/php.internals/90940) I don't think the session
> extension is in a state where incremental improvements are a good way
> to proceed:
>
>> The problem is that you're trying to build on a foundation of sand.
>> The session handling works but is incredibly fragile.
>
>> To me, there are two good ways to proceed:
>
>> i) Develop a new session extension, that doesn't depend on magic
>> behaviour of globals and leave the current session handler as it is.
>> The new session extension could be shipped as a 'work in progress' when
>> it's good enough, before PHP 8. Then when it's stable, we could figure
>> out how to transition users from the old extension.

Basic design of session module is good enough, IMHO.
Even if we rewrite session module, it will end up with similar
implementation. Complexity of state(session) management cannot be
reduced by rewrite.

Object interface has/had lots of problems. This part could be improved
one by one. If nobody objects, I can clean them up with a single RFC.

>>
>> ii) Develop a session handler in userland code only. PHP is powerful
>> enough to support this. Although obviously there are big benefits to
>> shipping a session handler with PHP, I don't see any need for it to be
>> done internally other than we don't currently have a way of shipping
>> userland code with an extension. I'm hoping that before PHP 8, the
>> ability to ship PHP code as part of extensions would be in place.

I think this is not good option. Session management is complex and
difficult to understand what it should be. I've proposed both
minimal/simple and complex/comprehensive timestamp based session
management which is mandatory for session management, but both of RFCs
are declined. I suppose this proved difficulty of proper session
management. It's slow when it is implemented as PHP script also.

Regards,

--
Yasuo Ohgaki
yohg...@ohgaki.net

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: [RFC][VOTE] Session ID without hashing

[Dan Ackroyd]

Hi Yasuo,

> Could you share the reason why against this change?

The RFC is doing separate things:

* Using a proper random number generator - which is probably a good
thing, and I probably would vote/support that change by itself.

* Removing old stuff for performance reasons - probably a bad thing,
as minor performance improvements don't justify changing the ini
settings imo.

* Slipping in a change to make 'session.use_strict_mode' be enbled by
default. I actually agree with this change, but I don't like how it's
been combined into an unrelated RFC.

* Exposing information that could be useful to an attacker, from the RFC:

> If PRNG has vulnerability that generates predictable value, exposing
> raw PRNG state helps attackers. Although, this is unlikely with modern PRNGs, 
> but
> risk is there.

I don't agree that faster session generation is worth exposing the
random number generator in a completely known way to the outside
world. Reading an extra 60 bytes almost certainly does nothing to
mitigate that exposure.

> cryptographers recommends
> not to reinvent crypt related functions/features.

They also recommend reducing your attack surface as much as possible,
not opening it up to the point where you're relying on the CSPRNG to
work perfectly to avoid having a security hole.

But more importantly, as I wrote before
(http://news.php.net/php.internals/90940) I don't think the session
extension is in a state where incremental improvements are a good way
to proceed:

> The problem is that you're trying to build on a foundation of sand.
> The session handling works but is incredibly fragile.

> To me, there are two good ways to proceed:

> i) Develop a new session extension, that doesn't depend on magic
> behaviour of globals and leave the current session handler as it is.
> The new session extension could be shipped as a 'work in progress' when
> it's good enough, before PHP 8. Then when it's stable, we could figure
> out how to transition users from the old extension.
>
> ii) Develop a session handler in userland code only. PHP is powerful
> enough to support this. Although obviously there are big benefits to
> shipping a session handler with PHP, I don't see any need for it to be
> done internally other than we don't currently have a way of shipping
> userland code with an extension. I'm hoping that before PHP 8, the
> ability to ship PHP code as part of extensions would be in place.

cheers
Dan

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: [RFC][VOTE] Session ID without hashing

[Yasuo Ohgaki]

Hi Stas,

Thank you for sharing opinion.
Followings is mine.

On Tue, Jul 5, 2016 at 7:23 AM, Stanislav Malyshev  wrote:
>> Could you share the reason why against this change?
>
> 1. I'm not sure exporting raw generator state is a good practice. I may
> change my opinion on the subject if I hear from some security people
> (I'm no crypto expert) that this is ok, then I may change my opinion.

I think no one can guarantee security of CSPRNG on all platforms.

"CS" means cryptographic safety and cryptographers recommends
not to reinvent crypt related functions/features.

> 2. Due to (1), I do not think it makes sense to do this change, because
> we produce no benefit (session generation speed is not that important
> since nobody generates millions of sessions at once) and create
> potential problems.

Current implementation is regenerating random hash string by using

 - PID
 - Time (Simple random function)
 - CSPRNG when it is available


10 years ago, I would agree with your opinion, since old PRNG is not
as good as current one.

Today, I don't see the reason why we should reinvent secure random
bytes as we do now.

I agree we should have some mitigations just in case a CSPRNG is
broken badly. The patch uses 4 to 6 bits to generate readable string
and read extra 60 bytes to hide raw PRNG state. This mitigation should
be good enough for somewhat broken CSPRNG. In addition, even when
CSPRNG generates the same random bytes, session module has collision
detection and will not create the same session ID.

I hope you and others are convinced by this explanation.

Regards,

--
Yasuo Ohgaki
yohg...@ohgaki.net

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: [RFC][VOTE] Session ID without hashing

[Stanislav Malyshev]

Hi!

> Could you share the reason why against this change?

1. I'm not sure exporting raw generator state is a good practice. I may
change my opinion on the subject if I hear from some security people
(I'm no crypto expert) that this is ok, then I may change my opinion.

2. Due to (1), I do not think it makes sense to do this change, because
we produce no benefit (session generation speed is not that important
since nobody generates millions of sessions at once) and create
potential problems.

-- 
Stas Malyshev
smalys...@gmail.com

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: [RFC][VOTE] Session ID without hashing

[Yasuo Ohgaki]

Hi Stas and Danack

On Sat, Jul 2, 2016 at 4:35 PM, Yasuo Ohgaki  wrote:
> This proposal cleans up session code by removing hash.
>
> https://wiki.php.net/rfc/session-id-without-hashing
>
> I set vote requires 2/3 support.
> Please describe the reason why when you against this RFC. Reasons are
> important for improvements!
>
> Thank you!

Could you share the reason why against this change?

Thank you!

--
Yasuo Ohgaki
yohg...@ohgaki.net

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php