Comment 2 for bug 1618615

Ok, A couple of comments here:

Tenant IDs are UUID4 (previous incarnations back in the original days not withstanding) and should not be purely bruteforceable as are user_ids. The example you referenced is poor in that it is very contrived values; this however does not imply a lack of security issue here.

This only affects ec2 credentials, normal credentials get the standard uuid generation:
https://github.com/openstack/keystone/blob/f7f1ee74350f62cb3e3fe9e7eb3adc0eaa99d85e/keystone/credential/controllers.py#L62

It looks like in the code creating EC2 credentials, the access token is in-fact a uuid.uuid4():

https://github.com/openstack/keystone/blob/f7f1ee74350f62cb3e3fe9e7eb3adc0eaa99d85e/keystone/contrib/ec2/controllers.py#L181-L191

Overall this looks to be generally an impractical security risk (guessing uuids). The blocking of "credential" would likewise be impractical since the DB should fill up long before a uuid4 or sha256 collides when it comes from a uuid4 source material.

There is a minor concern with the lack of entropy when converting a uuid4 to a SHA256 sum.

Finally, the "500" error should be a separate bug and is not part of the security related issues.

With all the above information, I am guessing this is a "Class D" bug https://security.openstack.org/vmt-process.html#incident-report-taxonomy

I'll wait for confirmation from the rest of the keystone coresec team before making any changes/updates here.