Re: [RFC] [Discussion] Secure session_regenerate_id()

From: Date: Wed, 19 Mar 2014 18:35:40 +0000
Subject: Re: [RFC] [Discussion] Secure session_regenerate_id()
References: 1  Groups: php.internals 
Request: Send a blank email to internals+get-73306@lists.php.net to get a copy of this message
Hi! > Secure session_regenerate_id() > https://wiki.php.net/rfc/session_regenerate_id Reading this RFC, I have the following thoughts: 1. The name is a misnomer. session_regenerate_id is secure with "true" setting that deletes the session immediately. There's no security problem there. There might be usability problem for those that want to keep session around longer, but that's a different thing. Claiming that this RFC is necessary for secure session regeneration is not correct. 2. This functionality (limited-time soft deletion) can be very easily implemented in user-space - just add the timestamp before doing the regenerate and then checking for that variable in session_start. The amount of code that needs to be added is very small so I don't see why it requires any changes in the engine. 3. Session functions never threw exceptions and making them throw exceptions would break existing code, resulting in fatal errors. I don't think it is a good idea to do such thing in a minor version. If we move in next major to more widespread exception usage, it'd be fine but such as it is now, exceptions would certainly not be expected coming from session_start. I'm also not sure what such exception would be useful for. So, say, somebody accesses your site with stale session. You can not know if it were an attack or just some user clicking an old link with a stale cookie. You can not do anything with it but issue new session. So why have that exception at all? -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227

« previous php.internals (#73306) next »