<html><head><style>body{font-family:Helvetica,Arial;font-size:13px}</style></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;">I’ve been looking over the code for this and it turns out plain old SHA1 is a bad idea.  We recently had a patch land in keystone client and keystone to let us configure the hashing algorithm used for token revocation list and the short-token ids. </div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;"><br></div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;">I’ve updated my patch set to use ‘{OBSCURED}%(token)s’ instead of specifying a specific obscuring algorithm. This means that if we ever update the way we obscure the data in the future, we’re not lying about what was done in the log. The proposed approach can be found here: https://review.openstack.org/#/c/99432</div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;"><br></div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;">Cheers,</div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;">Morgan</div> <div id="bloop_sign_1402547220588788992" class="bloop_sign"><p><strong>—</strong><br><strong>Morgan Fainberg</strong></p></div> <div style="color:black"><br>From: <span style="color:black">Jay Pipes</span> <a href="mailto:jaypipes@gmail.com">jaypipes@gmail.com</a><br>Reply: <span style="color:black">OpenStack Development Mailing List (not for usage questions)</span> <a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a><br>Date: <span style="color:black">June 11, 2014 at 12:49:35</span><br>To: <span style="color:black">openstack-dev@lists.openstack.org</span> <a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a><br>Subject: <span style="color:black"> Re: [openstack-dev] masking X-Auth-Token in debug output - proposed consistency <br></span></div><br> <blockquote type="cite" class="clean_bq"><span><div><div></div><div>On 06/11/2014 03:01 PM, Sean Dague wrote:

<br>> We've had a few reviews recently going around to mask out X-Auth-Token

<br>> from the python clients in the debug output. Currently there are a mix

> of ways this is done.

<br>>

<br>> In glanceclient (straight stricken)

<br>>

<br>> X-Auth-Token: ***

<br>>

<br>> The neutronclient proposal -

<br>> https://review.openstack.org/#/c/93866/9/neutronclient/client.py is to

<br>> use 'REDACTED'

<br>>

<br>> There is a novaclient patch in the gate that uses SHA1(<sha1oftoken>) -

<br>> https://review.openstack.org/#/c/98443/

<br>>

<br>> Morgan was working on keystone.session patch -

<br>> https://review.openstack.org/#/c/98443/

<br>>

<br>> after some back and forth we landed on {SHA1}<sha1oftoken> because

<br>> that's actually LDAP standard for such things, and SHA1(...) looks too

<br>> much like a function. I think that should probably be our final solution

<br>> here.

<br>>

<br>> Why SHA1?

<br>>

<br>> While we want to get rid of the token from the logs, for both security

<br>> and size reasons (5 - 10% of the logs in a gate run by bytes are

<br>> actually keystone tokens), it's actually sometimes important to

<br>> understand that *the same* token was used between 2 requests, or that 2

<br>> different tokens were used. This is especially try with expiration times

<br>> defaulting to 1 hr, and the fact that sometimes we have tests take

<br>> longer than that (so we need to debug that we didn't rotate tokens when

> we should have).

<br>>

<br>> Because the keystone token is long (going north of 4k), and variable

<br>> data length, and with different site data, these values should not be

<br>> susceptible to a generic rainbow attack, so a single SHA1 seems

<br>> sufficient. If there are objections to that, we can field something else

<br>> there. It also has the advantage of being "batteries included" with all

> our supported versions of python.

<br>>

<br>> I'm hoping we can just ACK this approach, and get folks to start moving

> patches through the clients to clean this all up.

<br>>

> If you have concerns, please bring them up now.

<br>

Sounds like an excellent plan, thx for the update, Sean.

<br>

<br>Best,

<br>-jay

<br>

<br>

<br>_______________________________________________

<br>OpenStack-dev mailing list

<br>OpenStack-dev@lists.openstack.org

<br>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

<br></div></div></span></blockquote></body></html>