Open Stack

Relevant etherpad -
https://etherpad.openstack.org/p/icehouse-token-revocation

In the etherpad, we reverted the example for "explicit token revocation
called on a single token" to use "expires_at" as the identifier for the
event (rather than a hash of the token). Because rescoping tokens maintains
the expiration of the original token, a single revocation event can revoke
an entire chain at once.

There's still a small chance of collision (revoking more tokens than
intended), but I don't think it's worth complicating the design further to
solve, as explicit token revocations are rare (relative to authorization
changes, etc).


On Tue, Nov 12, 2013 at 12:59 PM, Eric Windisch <eric at cloudscaling.com>wrote:

> During the token revocation discussion at the summit, I suggested it
> would be possible to revoke tokens using a hash of the token id (which
> is already an MD5 hash). That way, the revocation file would be able
> to specify individual hashes for revocation without dangerously
> presenting secrets.
>
> I should amend that suggestion to say that should this be done, the
> hash will need to be salted. Otherwise, rainbow tables could be used
> to attack the original secrets. In fact, this would be exacerbated by
> the fact there would be a limited domain to the hash function, knowing
> that the input would always be the 128bit output of MD5.
>
> This much might be obvious, but I felt it was worth clarifying and
> etching into the blueprint or other design documentation.
>
> --
> Regards,
> Eric Windisch
>



-- 

-Dolph
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131112/2eb00ef4/attachment.html>