Tickets :: Comment on [#12136] Session Timeout not enforced

* Your Email Address
* Spam protection	Enter the letters below: . .. . __.. . __. \| \|\|__\|(__ \|\ \|(__ \|__\|\| \|.__)\| \\|.__)
Comment	>>> 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....
Attachment
Watch this ticket

Saved Queries