On 24 March 2016 at 14:43, Scott Arciszewski <sc...@paragonie.com> wrote:
> 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/> > > > I had considered this suggestion myself, but I wasn't sure if it would be easy to implement. It could also cause some very strange (to a novice developer) behaviour which would be hard to debug (Think sites which have part http part https, session behaviour would be dependant on the entry page the user hits) I'd support this, but it should probably be opt-in to start with (alternatively we could come up with a different way to allow the developer to specify sessions being ssl only)
