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 <e...@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
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
