[Tickets #12136] Re: Session Timeout not enforced

[noreply at bugs.horde.org]

DO NOT REPLY TO THIS MESSAGE. THIS EMAIL ADDRESS IS NOT MONITORED.

Ticket URL: http://bugs.horde.org/ticket/12136
------------------------------------------------------------------------------
  Ticket             | 12136
  Updated By         | o+horde at immerda.ch
  Summary            | Session Timeout not enforced
  Queue              | Horde Framework Packages
  Version            | Git master
  Type               | Bug
  State              | Feedback
  Priority           | 2. Medium
  Milestone          |
  Patch              |
  Owners             |
------------------------------------------------------------------------------


o+horde at immerda.ch (2013-05-01 19:08) wrote:

>> as far as i can tell, they make the problem worse, as they combine
>> cookie lifetime and gc_maxlifetime into one config setting. so now i
>> cannot even get the weak security properties of setting
>> gc_maxlifetime, since it also affects cookie lifetime.
>
> Huh?  How does this make things worse?  This doesn't affect session  
> timeouts.  This only affects COOKIE timeouts.

no, after your changes, this config option now sets the gc_timeout  
*and* cookie timeout to always the same value.

if i want to set gc_timeout to n seconds but cookie timeout to 0 (like  
you suggest) then i'm now deprived of any option to do that. In a  
typical setup (as many other webservices deploy) the session timeout  
would be ~30mins and the maximal session lifetime ~2h. so the attack  
window quadruples if you remove the possibility to set gc_timeout  
independently.

> You have yet to explain HOW it is a "security issue" when, for   
> example, a session lasts 35 minutes and the session timeout value is  
>  actually 30 minutes.  What about those extra 5 minutes makes it a   
> "security issue"?

I already explained that i'm not talking about 5 mins, but several  
more. so i don't see an argument here. additionally, by coupling  
session and cookie timeout, this discussion becomes obsolete, so why  
do you argue about 5 mins, when there is no usable timeout mechanism  
and max_time is enforced to the second already.

> Session timeouts are not (and should  not) be an exact value.

why do you just say that, when every other webmail software disagrees  
with you?

> Session timeouts are there to prevent a  SINGLE attack vector:  
> someone manages to obtain your session  credentials/ID (the  
> assumption being that this takes time) and can  then use this to  
> access an unexpired session at some point in the  future.

why should it take time to get the session id? this assumption is  
completely bogus. i guess the most likely attack vector is someone not  
closing the browser on a public client (e.g. closing tab or walking  
away) therefore it is crucial to minimize the attack window. the  
attack window starts when the user makes his last action and ends when  
the session timeouts. it should not be > 20 minutes in my opinion.

> Not to mention the idea of a session "timeout" being the last time  
> you  accessed a server is a dangerous concept.  If using something  
> like  dynamic IMP, your session will NEVER time out.  So your  
> proposal  actually opens up additional security holes.

then i would consider this a bug to the session timeout mechanism,  
since it should detect real user action vs. automatic refresh.

> The only way to correctly "timeout" a session is to implement a time  
>  limit AT THE TIME OF THE INITIAL AUTHENTICATION.  This is what we   
> provide via the max_time configuration option.

ok i'm repeating myself. this is not true, there is a common threat  
model (not closing the browser) and a simple technical solution  
(timeout a session some minutes after the last real user activity) and  
almost all reasonable webservices which have some sort of a login  
system do exactly that.

> Anything else might  help in certain situations (e.g. a single user  
> system) but will hurt  in other situations (a single user system  
> where the user never closes  their browser).

then consider all the situations....