[dev] Token lifetimes (was Re: [imp] EMERG: HORDE Diese Anfrage konnte nicht durchgeführt werden)
Michael M Slusarz
slusarz at horde.org
Wed Oct 30 23:17:46 UTC 2013
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]
More information about the dev
mailing list