Open Stack

> 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/01cabf6bbbee
> > 8b5340295f3be5e1fa7111387e7d/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

From: Morgan Fainberg [mailto:morgan.fainberg at gmail.com]
>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).

Thanks for all the input.  Stuart McLaren pointed out the patches in Nova and Swift clients where using the SHA1 was done in place of the token, so I've gone ahead and posted up a glanceclient patch using the same approach.

https://review.openstack.org/#/c/121692/

Hopefully this at least makes these client work similarly for now and we can switch everything to the audit ID soon.

Thanks,
Travis