[imp] Token lifetimes (was Re: EMERG: HORDE Diese Anfrage konnte nicht durchgeführt werden)
Samuel Wolf
samuel at sheepflock.de
Wed Oct 30 23:36:31 UTC 2013
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'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.
Exactly this is the problem.
My users open IMP, Kronolith,... in different browser tabs and do not
work with IMP some times for an hour.
After this time they will get this error in IMP, but switch to
Kronolith (in the IMP browser tab) and back to
IMP solve the problem.
Samuel
>
> 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
More information about the imp
mailing list