I'm exploring the rcmail_session class to hunt down some intermittent issues with untimely session expiration, and to develop a better remember_me extension (or attempt to get it into core...).
I came across the following code
... /** * Setter for session lifetime */ public function set_lifetime($lifetime) { $this->lifetime = max(120, $lifetime);
// valid time range is now - 1/2 lifetime to now + 1/2 lifetime
$now = time();
$this->now = $now - ($now % ($this->lifetime / 2));
}
... /**
* Create session cookie from session data
*
* @param int Time slot to use
*/
function _mkcookie($timeslot)
{
$auth_string = "$this->key,$this->secret,$timeslot";
return "S" . (function_exists('sha1') ? sha1($auth_string) : md5($auth_string));
}
... /** * Check session authentication cookie * * @return boolean True if valid, False if not */ function check_auth() { ... if ($result && $this->_mkcookie($this->now) != $this->cookie) { ... }
It's quite deliberate, and it made me curious as to the reasoning behind the decision not to simply include a 'created_at' and 'expires_at' within the cookie, which would simplify the validation of the timespan. Is the reason for security, or perhaps a load-balancing?
Afaik that's the usual technique against session theft in php. Lot of php apps look the same.
Stephane Le 11 sept. 2013 23:13, "Rodrigo Castillo" rodrigo@corp.sonic.net a écrit :
I'm exploring the rcmail_session class to hunt down some intermittent issues with untimely session expiration, and to develop a better remember_me extension (or attempt to get it into core...).
I came across the following code
... /** * Setter for session lifetime */ public function set_lifetime($lifetime) { $this->lifetime = max(120, $lifetime);
// valid time range is now - 1/2 lifetime to now + 1/2 lifetime $now = time(); $this->now = $now - ($now % ($this->lifetime / 2)); }
... /**
* Create session cookie from session data * * @param int Time slot to use */ function _mkcookie($timeslot) { $auth_string = "$this->key,$this->secret,$**timeslot"; return "S" . (function_exists('sha1') ? sha1($auth_string) :
md5($auth_string)); } ... /** * Check session authentication cookie * * @return boolean True if valid, False if not */ function check_auth() { ... if ($result && $this->_mkcookie($this->now) != $this->cookie) { ... }
It's quite deliberate, and it made me curious as to the reasoning behind the decision not to simply include a 'created_at' and 'expires_at' within the cookie, which would simplify the validation of the timespan. Is the reason for security, or perhaps a load-balancing? ______________________________**_________________ Roundcube Development discussion mailing list dev@lists.roundcube.net http://lists.roundcube.net/**mailman/listinfo/devhttp://lists.roundcube.net/mailman/listinfo/dev
Hmmm yes. Basically its more or less crypto signature of cookies, but the signature only remains valid for a period of time, as the timestamp is part of auth_string.
So an evil user or intruder cant manipulate cookies on the client side.
On Thu, Sep 12, 2013 at 2:24 AM, stephane martin stef.martin@gmail.comwrote:
Afaik that's the usual technique against session theft in php. Lot of php apps look the same.
Stephane Le 11 sept. 2013 23:13, "Rodrigo Castillo" rodrigo@corp.sonic.net a écrit :
I'm exploring the rcmail_session class to hunt down some intermittent
issues with untimely session expiration, and to develop a better remember_me extension (or attempt to get it into core...).
I came across the following code
... /** * Setter for session lifetime */ public function set_lifetime($lifetime) { $this->lifetime = max(120, $lifetime);
// valid time range is now - 1/2 lifetime to now + 1/2 lifetime $now = time(); $this->now = $now - ($now % ($this->lifetime / 2)); }
... /**
* Create session cookie from session data * * @param int Time slot to use */ function _mkcookie($timeslot) { $auth_string = "$this->key,$this->secret,$**timeslot"; return "S" . (function_exists('sha1') ? sha1($auth_string) :
md5($auth_string)); } ... /** * Check session authentication cookie * * @return boolean True if valid, False if not */ function check_auth() { ... if ($result && $this->_mkcookie($this->now) != $this->cookie) { ... }
It's quite deliberate, and it made me curious as to the reasoning behind the decision not to simply include a 'created_at' and 'expires_at' within the cookie, which would simplify the validation of the timespan. Is the reason for security, or perhaps a load-balancing? ______________________________**_________________ Roundcube Development discussion mailing list dev@lists.roundcube.net http://lists.roundcube.net/**mailman/listinfo/devhttp://lists.roundcube.net/mailman/listinfo/dev
Rodrigo Castillo wrote:
I'm exploring the rcmail_session class to hunt down some intermittent issues with untimely session expiration, and to develop a better remember_me extension (or attempt to get it into core...).
I came across the following code
... /** * Setter for session lifetime */ public function set_lifetime($lifetime) { $this->lifetime = max(120, $lifetime);
// valid time range is now - 1/2 lifetime to now + 1/2 lifetime $now = time(); $this->now = $now - ($now % ($this->lifetime / 2)); }
... /**
* Create session cookie from session data * * @param int Time slot to use */ function _mkcookie($timeslot) { $auth_string = "$this->key,$this->secret,$timeslot"; return "S" . (function_exists('sha1') ? sha1($auth_string) :
md5($auth_string)); } ... /** * Check session authentication cookie * * @return boolean True if valid, False if not */ function check_auth() { ... if ($result && $this->_mkcookie($this->now) != $this->cookie) { ... }
It's quite deliberate, and it made me curious as to the reasoning behind the decision not to simply include a 'created_at' and 'expires_at' within the cookie, which would simplify the validation of the timespan. Is the reason for security, or perhaps a load-balancing?
The main reasons to encode a "timeslot" into the second cookie are:
the risk of session hijacking.
and we don't need to update the actual session data on every request just to extend the expiration date.
Regards, Thomas