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
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