Comment 8 for bug 1618615

Re: #5 It is not true that the user has to "guess" here - if they already have the access key, they can confirm/disconfirm that it is in use by Keystone without any guesswork (the SHA256 of the access key is deterministic - the SHA256 of the access key is either present, indicating use of that access key, or it isn't). It is of course up to the team to decide whether this is a risk worth mitigating.

Re: #7 - I would disagree that they are "going around the API." The API allows you to put whatever you want in the "access" key, and nowhere in the documentation does it even make reference to UUIDs. It is true that they would have to be accessing the API _manually_, but they're not doing anything special to force the API to accept non-UUIDs.

If UUIDs are supposed to be the only thing the API accepts, they should be enforced on the credentials creation endpoint. That is different from having one potential path by which users would automatically generate UUIDs, but free rein to insert whatever else they want manually. Perhaps at least a minimum length on the access key would be a good mitigating control.