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

Gunnar Wrobel p at rdus.de
Tue Nov 30 15:41:42 UTC 2010


Quoting Jan Schneider <jan at horde.org>:

> 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.

Okay, I'll switch that.

>
>> - 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?

The "auth_key"? I wasn't aware that I could reuse it because of the  
name "auth". Will do that.

>
>> - 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.

Okay, Horde_Nonce will vanish again.

Thanks for the feedback!

>
> Jan.
>
> -- 
> Do you need professional PHP or Horde consulting?
> http://horde.org/consulting/
>
>
> -- 
> Horde developers mailing list - Join the hunt: http://horde.org/bounties/
> Frequently Asked Questions: http://horde.org/faq/
> To unsubscribe, mail: dev-unsubscribe at lists.horde.org
>







More information about the dev mailing list