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
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
