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

[Samuel Wolf]

Zitat von Michael M Slusarz <slusarz at horde.org>:

> 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 must increase the timeout to 720 minutes, 120 minutes was not enough,
the users come to me with the timeout printouts of mails.

>
> 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]
>
> -- 
> imp mailing list
> Frequently Asked Questions: http://wiki.horde.org/FAQ
> To unsubscribe, mail: imp-unsubscribe at lists.horde.org