Open Stack

-----Original Message-----
From: Brant Knudson <blk at acm.org>
Reply: OpenStack Development Mailing List (not for usage questions) <openstack-dev at lists.openstack.org>>
Date: September 12, 2014 at 14:32:20
To: OpenStack Development Mailing List (not for usage questions) <openstack-dev at lists.openstack.org>>
Subject:  Re: [openstack-dev] masking X-Auth-Token in debug output - proposed consistency

> On Fri, Sep 12, 2014 at 12:02 PM, Tripp, Travis S  
> 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} 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

Ideally, I want to see the use of the audit_ids (in each token as of Juno) as the end goal. If we can get there as fast as changing to the {SHA1}, I’d advocate for that. Brant nicely outlined why we didn’t go with SHA1 earlier on in the cycle.

I think we are close to solving this in a better way than using sha1, but if we need a stop-gap we can go towards that for the short term (and disallow sha1 as a hash for Keystone).

—Morgan