<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Sep 12, 2014 at 12:02 PM, Tripp, Travis S <span dir="ltr"><<a href="mailto:travis.tripp@hp.com" target="_blank">travis.tripp@hp.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
>From Jamie Lennox:<br>
<span class="">>> We handle this in the keystoneclient Session object by just printing REDACTED or something similar.<br>
>> The problem with using a SHA1 is that for backwards compatability we often use the SHA1 of a PKI token<br>
>> as if it were a UUID token and so this is still sensitive data. There is working in keystone by morganfainberg<br>
>> (which i think was merged) to add a new audit_it which will be able to identify a token across calls without<br>
>> exposing any sensitive information. We will support this in session when available.<br>
<br>
</span>From Sean Dague<br>
<span class="">> So the problem is that means we are currently leaking secrets and making the logs unreadable.<br>
<br>
> It seems like we should move forward with the {SHA1} ... and if that is still sensitive, address that later.<br>
> Not addressing it basically keeps the exposure and destroys usability of the code because there is so much garbage printed out.<br>
<br>
</span>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.<br>
<br>
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?<br>
<br>
If only for consistency sake, I could switch to "TOKEN_REDACTED" like the code sample Morgan sent. [1]<br>
<br>
[1] <a href="https://github.com/openstack/python-keystoneclient/blob/01cabf6bbbee8b5340295f3be5e1fa7111387e7d/keystoneclient/session.py#L126-L131" target="_blank">https://github.com/openstack/python-keystoneclient/blob/01cabf6bbbee8b5340295f3be5e1fa7111387e7d/keystoneclient/session.py#L126-L131</a><br></blockquote><div><br></div><div>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.<br><br></div><div>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.<br></div><div><br></div><div>- Brant<br></div><br></div></div></div>