-----Original Message----- From: Brant Knudson <b...@acm.org> Reply: OpenStack Development Mailing List (not for usage questions) <openstack-dev@lists.openstack.org>> Date: September 12, 2014 at 14:32:20 To: OpenStack Development Mailing List (not for usage questions) <openstack-dev@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 _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev