[dev] New token variant (was: Re: [commits] Horde branch master updated. 1e943c0937d592233379d8cac82b89f80861b11c)

Jan Schneider jan at horde.org
Tue Nov 30 14:00:57 UTC 2010


Zitat von Gunnar Wrobel <p at rdus.de>:

> Quoting Gunnar Wrobel <p at rdus.de>:
>
>> commit 0e6c059c857152a54cd55efc9b3afb04183baea3
>> Author: Gunnar Wrobel <p at rdus.de>
>> Date:   Tue Nov 30 13:46:07 2010 +0100
>>
>>    Exchange the session based logout token with the timestamped  
>> token variant as an example.
>>
>> framework/Core/lib/Horde/Registry.php |    2 +-
>> horde/login.php                       |    2 +-
>> 2 files changed, 2 insertions(+), 2 deletions(-)
>>
>> http://git.horde.org/horde-git/-/commit/0e6c059c857152a54cd55efc9b3afb04183baea3
>
> I finally managed to complete the main part of what I started with  
> the Horde_Nonce system. The Horde_Token_Base class now supports a  
> new token type.
>
> The main reason for introducing these tokens is that there is no  
> need to store them in the session anymore. We did that before in  
> order to handle token expiration. That part is now handled via a  
> time stamp contained within the token.
>
> These tokens are composed of a time stamp, a "nonce" (random number)  
> and a sha256 hash of time stamp, nonce, seed/slug, and user secret.  
> The latter one is based on Horde_Secret.
>
> The time stamp and the nonce can be extracted from the token and do  
> not add anything in terms of security. The time stamp is used for  
> token expiration and the nonce can be used for unique tokens that  
> may not be invalidated twice.
>
> The main changes in case people browse the commits:
>
>  - Horde_Core_Factory_Token now provides the secret to the token  
> system thereby
>    creating a new cookie ("token_key") on the user side  
> (http://git.horde.org/horde-git/-/commit/0adff3f9ba4c6c4f48d68931d34b8d4120a577fc).
>    In addition the configuration parameter $conf['urls']['token_lifetime'] is
>    also transported to the token system.
>
>  - The token system now takes responsibility for throwing the required
>    Exceptions (which was done by Horde::get/checkRequestToken before.
>
>  - The tokens can be checked via
>
>    $injector->getInstance('Horde_Token')->isValid($token, $seed)
>
>    or
>
>    $injector->getInstance('Horde_Token')->isValidAndUnused($token, $seed)
>
>    The second variant is for unique tokens.
>
>  - An alternative is
>
>    $injector->getInstance('Horde_Token')->validate($token, $seed, $timeout,
>                                                    $unique)
>
>    This one doesn't throw exceptions but just returns a boolean value.

This doesn't make sense, is that a typo? is*() methods should return  
booleans. validate() may throw an Exception.

>  - In case a token is validated and requested to be unique the timestamp +
>    nonce will be stored in the standard token invalidation system.
>
>
> ToDo (in case nobody disagrees):
>
>  - Conversion of old tokens to new tokens.
>
>  - Move of translations for exceptions from "Core" to "Token".
>
>  - Removal of Horde::get/checkRequestToken
>
> Questions:
>
>  - Do I need to kill the new "token_key" cookie explicitly on login/logout?

Why didn't you re-use the existing Horde_Secret cookie?

>  - Do the current storage solutions we use for "unique tokens" (SQL or file
>    based) pose a notable problem on large installations? The reason  
> I'm asking
>    is because I realized the bloom filter approach in Horde_Nonce is really
>    only useful to reduce the amount of storage required when  
> remembering tokens
>    that have already been used. And in case our current approach is just fine
>    I would simply delete Horde_Nonce again and rely on the simple stuff I
>    did in Horde_Token now.

I never heard of any problems with those.

Jan.

-- 
Do you need professional PHP or Horde consulting?
http://horde.org/consulting/



More information about the dev mailing list