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/>