[imp] Token lifetimes (was Re: EMERG: HORDE Diese Anfrage konnte nicht durchgeführt werden)

[Michael M Slusarz]

Quoting Samuel Wolf <samuel at sheepflock.de>:

> Zitat von Michael M Slusarz <slusarz at horde.org>:
>
>> Quoting samuel at sheepflock.de:
>>
>>> Hi,
>>>
>>> I update yesterday to the current horde release (horde 5.1.5, imp 
>>> 6.1.5,..) and see this error today when I print a mail:
>>> 2013-10-30T15:16:49+00:00 EMERG: HORDE [imp] Diese Anfrage konnte 
>>> nicht durchgeführt werden, weil der Link oder das Formular, das Sie 
>>> abgeschickt haben, nur 30 Minuten gültig war. Bitte versuchen Sie es 
>>> jetzt noch einmal. [pid 18110 on line 167 of 
>>> "/usr/share/php/Horde/Token/Base.php"]
>>>
>>> Switch Horde app, mailfolder or message (sorry can not remember) and 
>>> it work again.
>>> Somebody a idea what went wrong?
>>> Some timeout, because it work over hours before...
>>
>> Increase your token timeout.
>
> This one?
> conf.php:$conf['urls']['token_lifetime'] = 30;

Yes.

I'm wondering if we shouldn't get rid of this entirely and simply  
revert to per session tokens.  At least for authenticated people.   
(And even for guest users, we are assuming that have a session when  
accessing application resources, right?  )

For example: It's not that uncommon to open a message, get distracted,  
and then try to open a token-protected URL more than 30 minutes later.

Session tokens are designed to prevent *static* CSRF attacks.  Having  
a session-length token prevents these attacks.

Changing tokens within the session is meant to prevent *dynamic*  
attacks.  I don't think we gain much since if an attacker has to  
somehow gain access to your session information and grab the token to  
perform the attack 1) they are probably going to launch a more direct  
attack anyway (since, to get this information, they have likely gained  
access through a different security hole), and 2) it won't even reach  
this point, since an attacker will switch to another service that  
doesn't token protect in the first place.

michael

___________________________________
Michael Slusarz [slusarz at horde.org]