[openstack-dev] masking X-Auth-Token in debug output - proposed consistency

John Dickinson me at not.mn
Wed Jun 11 19:44:29 UTC 2014


For both the security and the log line length, Swift is by default just displaying the first 16 bytes of the token.

--John



On Jun 11, 2014, at 12:39 PM, Morgan Fainberg <morgan.fainberg at gmail.com> wrote:

> 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 sean at dague.net
> Reply: OpenStack Development Mailing List (not for usage questions) openstack-dev at lists.openstack.org
> Date: June 11, 2014 at 12:02:20
> To: OpenStack Development Mailing List (not for usage questions) openstack-dev at lists.openstack.org
> Subject:  [openstack-dev] masking X-Auth-Token in debug output - proposed consistency 
> 
>> 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 - 
>> https://review.openstack.org/#/c/93866/9/neutronclient/client.py is to 
>> use 'REDACTED' 
>> 
>> There is a novaclient patch in the gate that uses SHA1(<sha1oftoken>) - 
>> https://review.openstack.org/#/c/98443/ 
>> 
>> Morgan was working on keystone.session patch - 
>> https://review.openstack.org/#/c/98443/ 
>> 
>> 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 
>> here. 
>> 
>> 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 
>> 
>> -- 
>> Sean Dague 
>> http://dague.net 
>> 
>> _______________________________________________ 
>> OpenStack-dev mailing list 
>> OpenStack-dev at lists.openstack.org 
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140611/75fc5f3b/attachment.pgp>


More information about the OpenStack-dev mailing list