Actually swiftclient is one of the biggest offenders in the gate -
http://logs.openstack.org/96/99396/1/check/check-tempest-dsvm-full/4501fc8/logs/screen-g-api.txt.gz#_2014-06-11_15_20_11_078

On 06/11/2014 03:44 PM, John Dickinson wrote:
> 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.fainb...@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 s...@dague.net
>> Reply: OpenStack Development Mailing List (not for usage questions) 
>> openstack-dev@lists.openstack.org
>> Date: June 11, 2014 at 12:02:20
>> To: OpenStack Development Mailing List (not for usage questions) 
>> openstack-dev@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@lists.openstack.org 
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 


-- 
Sean Dague
http://dague.net

Attachment: signature.asc
Description: OpenPGP digital signature

_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to