On Thu, Mar 24, 2016 at 9:55 AM, Chris Riley <t.carn...@gmail.com> wrote:

> On 24 March 2016 at 02:34, Yasuo Ohgaki <yohg...@ohgaki.net> wrote:
>
> > Hi all,
> >
> > Since the vote for
> > https://wiki.php.net/rfc/precise_session_management
> > is declined 15 vs 11.
> > https://wiki.php.net/rfc/precise_session_management#vote
> >
> > We have to come up with other solutions for
> >
> >  - Session loss by race conditions
> >  - Method to make session abuse harder
> >
> > I'm open to implement better solution than proposed RFC.
> >
> > These issues are serious issues that cannot be ignored.
> > Looking forward alternative implementation ideas!
> >
> > Thank you.
> >
> > --
> > Yasuo Ohgaki
> > yohg...@ohgaki.net
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
> >
> I'm disappointed this RFC failed as improving session security should be a
> high priority. I'd propose that we focus on items which will improve
> session security overall. This jumped out at me to start with: "This RFC
> also
> includes minor security improvements like httponly cookie, better hash
> function."
>
> Perhaps a first RFC for improving session security can start with those
> items: Set the session cookie to be httponly (or provide an ini setting to
> do so, defaulting to on) instead of using a better hash function for the
> session id, why not generate it from random_bytes()? Then the id is crypto
> secure.
>
> I'd then consider a second RFC setting out the extra internal data that
> would be required to kill off old sessions correctly. That would require to
> keys under ['__PHP__SESSION__'] (could the key name be an ini setting to
> preserve BC?) 'destroyed' and 'expires', the latter would be a bool flag
> stating if the session had been explicitly destroyed. (A destroyed session
> could no longer be used, could throw an exception or just have no data in
> it) the expires key would be used in a similar manner, being set to
> Time+cookie expiry time on each read/write to the session. (again an
> expired session would not be accessible and would function like a destroyed
> one)
>
> The combination of the two would resolve most of the security issues and
> establish the __PHP__SESSION__ key which could later be used to handle the
> race condition issue.
>

Could we also add HTTPS detection and enable the secure flag by default
when a session is established on an HTTPS endpoint?

Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises <https://paragonie.com/>
​

Reply via email to