> On description: s/as long as the user wasn't disabled/as long as the token wasn't otherwise revoked/
That brings up interesting point.
If I'm reading the keystone code correctly, only *non-expired* revoked tokens are returned from Driver.list_revoked_tokens(), at least in the SQL case:
So a token that has been both revoked *and* expired would not be reported as revoked (presumably the assumption here is that the token would fall in any case on the expiry-check hurdle, so no need to pollute the reported revoked list with really old tokens).
IIUC this makes the vulnerability a tad worse, as the effect of revocation is reversed if the token is re-used post-expiry.
@dolph
> On description: s/as long as the user wasn't disabled/as long as the token wasn't otherwise revoked/
That brings up interesting point.
If I'm reading the keystone code correctly, only *non-expired* revoked tokens are returned from Driver. list_revoked_ tokens( ), at least in the SQL case:
https:/ /github. com/openstack/ keystone/ blob/master/ keystone/ token/backends/ sql.py# L128
So a token that has been both revoked *and* expired would not be reported as revoked (presumably the assumption here is that the token would fall in any case on the expiry-check hurdle, so no need to pollute the reported revoked list with really old tokens).
IIUC this makes the vulnerability a tad worse, as the effect of revocation is reversed if the token is re-used post-expiry.