Open Stack

On Fri, Sep 12, 2014 at 12:02 PM, Tripp, Travis S <travis.tripp at hp.com>
wrote:

>
> From Jamie Lennox:
> >> We handle this in the keystoneclient Session object by just printing
> REDACTED or something similar.
> >> The problem with using a SHA1 is that for backwards compatability we
> often use the SHA1 of a PKI token
> >> as if it were a UUID token and so this is still sensitive data. There
> is working in keystone by morganfainberg
> >> (which i think was merged) to add a new audit_it which will be able to
> identify a token across calls without
> >> exposing any sensitive information. We will support this in session
> when available.
>
> From Sean Dague
> > So the problem is that means we are currently leaking secrets and making
> the logs unreadable.
>
> > It seems like we should move forward with the {SHA1} ... and if that is
> still sensitive, address that later.
> > Not addressing it basically keeps the exposure and destroys usability of
> the code because there is so much garbage printed out.
>
> I understand Sean's point about debugging.  Right now the glanceclient is
> just printing ***.  So it isn't printing a lot of excess and isn't leaking
> anything sensitive.  The other usability concern with the ***  that Sean
> previously mentioned was having a short usable string might be useful for
> debugging.
>
> Morgan and Jamie, You think switching to SHA1 in actually adds a potential
> security vulnerability to glanceclient that doesn't exist now. If that is
> true, I think it would override the additional debugging concern of using
> SHA1 for now.  Can you please confirm?
>
> If only for consistency sake, I could switch to "TOKEN_REDACTED" like the
> code sample Morgan sent. [1]
>
> [1]
> https://github.com/openstack/python-keystoneclient/blob/01cabf6bbbee8b5340295f3be5e1fa7111387e7d/keystoneclient/session.py#L126-L131
>

As the person who proposed the change to print TOKEN_REDACTED, I'd be happy
to see it printed as {SHA1}<token-sha1> instead. I only had it print
TOKEN_REDACTED because I was concerned that we were still logging tokens
and wanted to get something merged that didn't do that rather than waiting
for the perfect solution to come along.

Since we have configurable token hashing algorithm support in keystone and
auth_token middleware, it's possible that someone could lose their sanity
and decide to use sha1 as the hash algorithm (it defaults to MD5, which
some security standards say is inadequate), and now your logs have usable
token IDs instead of an unusable hash, ***, TOKEN_REDACTED, or whatever. We
could accept this as a risk, and we could mitigate the risk some by
changing keystone to reject sha1 as a hashing algorithm.

- Brant
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140912/c2da2b00/attachment.html>