This stems a bit further than just reduction in noise in the logs. Think of 
this from a case of security (with centralized logging or lower privileged 
users able to read log files). If we aren’t putting passwords into these log 
files, we shouldn’t be putting tokens in. The major functional different 
between a token and a password is that the token has a fixed life span. Barring 
running over the TTL of the token, the token grants all rights and privileges 
that user has (some exceptions, such as trusts), even allowing for a rescope of 
token to another project/tenant. In this light, tokens
are only marginally less exposure than a password in a log file.

I firmly believe that we should avoid putting information that conveys 
authorization (e.g. username/password or bearer token id) in the logs.
Morgan Fainberg

From: Sean Dague
Reply: OpenStack Development Mailing List (not for usage questions)
Date: June 11, 2014 at 12:02:20
To: OpenStack Development Mailing List (not for usage questions)
Subject:  [openstack-dev] masking X-Auth-Token in debug output - proposed 

We've had a few reviews recently going around to mask out X-Auth-Token  
from the python clients in the debug output. Currently there are a mix  
of ways this is done.  

In glanceclient (straight stricken)  

X-Auth-Token: ***  

The neutronclient proposal - is to  
use 'REDACTED'  

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

Morgan was working on keystone.session patch -  

after some back and forth we landed on {SHA1}<sha1oftoken> because  
that's actually LDAP standard for such things, and SHA1(...) looks too  
much like a function. I think that should probably be our final solution  

Why SHA1?  

While we want to get rid of the token from the logs, for both security  
and size reasons (5 - 10% of the logs in a gate run by bytes are  
actually keystone tokens), it's actually sometimes important to  
understand that *the same* token was used between 2 requests, or that 2  
different tokens were used. This is especially try with expiration times  
defaulting to 1 hr, and the fact that sometimes we have tests take  
longer than that (so we need to debug that we didn't rotate tokens when  
we should have).  

Because the keystone token is long (going north of 4k), and variable  
data length, and with different site data, these values should not be  
susceptible to a generic rainbow attack, so a single SHA1 seems  
sufficient. If there are objections to that, we can field something else  
there. It also has the advantage of being "batteries included" with all  
our supported versions of python.  

I'm hoping we can just ACK this approach, and get folks to start moving  
patches through the clients to clean this all up.  

If you have concerns, please bring them up now.  


Sean Dague  

OpenStack-dev mailing list  
OpenStack-dev mailing list

Reply via email to