Open Stack

>From new Mailing list thread: http://lists.openstack.org/pipermail
/openstack-dev/2014-September/045802.html

So, will propose fix similar to swift which copied from Nova.

-----Original Message-----
From: Morgan Fainberg [mailto:morgan.fainberg at gmail.com] 
Sent: Friday, September 12, 2014 3:39 PM
To: Brant Knudson; OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] masking X-Auth-Token in debug output - proposed consistency


-----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/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

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

-- 
You received this bug notification because you are a member of OpenStack
Security Group, which is subscribed to OpenStack.
https://bugs.launchpad.net/bugs/1329301

Title:
  Update how tokens are redacted

Status in Python client library for Glance:
  Incomplete

Bug description:
  We should move from this approach:

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

  to whatever cross-project approach is agreed upon:

  See this thread:

  http://lists.openstack.org/pipermail/openstack-
  dev/2014-June/037345.html

To manage notifications about this bug go to:
https://bugs.launchpad.net/python-glanceclient/+bug/1329301/+subscriptions