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

> On Fri, Sep 12, 2014 at 12:02 PM, Tripp, Travis S > wrote: > > > > > From Jamie Lennox: > > >> We handle this in the keystoneclient Session object by just > > >> printing > > REDACTED or something similar. > > >> The problem with using a SHA1 is that for backwards compatability > > >> we > >

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

-Original Message- From: Brant Knudson Reply: OpenStack Development Mailing List (not for usage questions) > Date: September 12, 2014 at 14:32:20 To: OpenStack Development Mailing List (not for usage questions) > Subject:  Re: [openstack-dev] masking X-Auth-Token in debug

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

On Fri, Sep 12, 2014 at 12:02 PM, Tripp, Travis S wrote: > > From Jamie Lennox: > >> We handle this in the keystoneclient Session object by just printing > REDACTED or something similar. > >> The problem with using a SHA1 is that for backwards compatability we > often use the SHA1 of a PKI token

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

>From Jamie Lennox: >> We handle this in the keystoneclient Session object by just printing >> REDACTED or something similar. >> The problem with using a SHA1 is that for backwards compatability we often >> use the SHA1 of a PKI token >> as if it were a UUID token and so this is still sensitive

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

On 09/11/2014 08:49 PM, Jamie Lennox wrote: > > > - Original Message - >> From: "Travis S Tripp" >> To: "OpenStack Development Mailing List (not for usage questions)" >> >> Sent: Friday, 12 September, 2014 10:30:53 AM >> Su

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

- Original Message - > From: "Travis S Tripp" > To: "OpenStack Development Mailing List (not for usage questions)" > > Sent: Friday, 12 September, 2014 10:30:53 AM > Subject: [openstack-dev] masking X-Auth-Token in debug output - propos

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

-Original Message- From: Tripp, Travis S Reply: OpenStack Development Mailing List (not for usage questions) > Date: September 11, 2014 at 17:35:30 To: OpenStack Development Mailing List (not for usage questions) > Subject:  [openstack-dev] masking X-Auth-Token in debug output - pr

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

Hi All, I'm just helping with bug triage in Glance and we've got a bug to update how tokens are redacted in the glanceclient [1]. It says to update to whatever cross-project approach is agreed upon and references this thread: http://lists.openstack.org/pipermail/openstack-dev/2014-June/037345.

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

The password dumping is actually in oslo apiclient. So that too should be scrubbed, but it has to happen in oslo first. So mostly just because I found it here. -Sean On 06/12/2014 10:47 PM, Xuhan Peng wrote: > Sorry to interrupt this discussion. > > Sean, > > Since I'm working the neu

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

Right, because your 'site' service catalog is encoded in them, they are big, of unpredictable length, and they are going to be differently seeded for every installation out there. Which is why rainbow tables didn't seem to be a valid threat to me. -Sean On 06/13/2014 05:09 AM, Kevin Bent

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

If these tokens are variable length up to 4k, it will make the search space much to large to construct any kind of useful table. They become infeasible for A-z0-9 variable-length password sets above 10 chars if you include every permutation. Assuming the tokens are generated in a very predictable m

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

On 12 June 2014 23:59, Sean Dague wrote: > The only thing it makes harder is you have to generate your own token to > run the curl command. The rest is there. Because everyone is running our > servers at debug levels, it means the clients are going to be running > debug level as well (yay python

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

On Fri, Jun 13, 2014 at 4:47 AM, Xuhan Peng wrote: > Since I'm working the neutron client code change, by looking at your code > change to nova client, looks like only X-Auth-Token is taken care of in > http_log_req. There is also password in header and token id in response. > Any particular reas

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

Sorry to interrupt this discussion. Sean,  Since I'm working the neutron client code change, by looking at your code change to nova client, looks like only X-Auth-Token is taken care of in http_log_req. There is also password in header and token id in response. Any particular reason that

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

> I'm hoping we can just ACK this approach, and get folks to start moving > patches through the clients to clean this all up. just an fyi, in pyCADF, we obfuscate tokens similar to how credit cards are handled: by capturing a percentage of leading and trailing characters and substituting the mid

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

On Thu, Jun 12, 2014 at 1:59 PM, Sean Dague  wrote: The only thing it makes harder is you have to generate your own token to run the curl command. The rest is there. Well I would have imagine that the curl command debug are here so people can easily copy and paste them and/or tweak them, but su

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

On Thu, Jun 12, 2014 at 1:59 PM, Sean Dague wrote: > The only thing it makes harder is you have to generate your own token to > run the curl command. The rest is there. > Well I would have imagine that the curl command debug are here so people can easily copy and paste them and/or tweak them, bu

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

On 06/12/2014 07:42 AM, Chmouel Boudjnah wrote: > On Thu, Jun 12, 2014 at 12:58 PM, Chmouel Boudjnah > wrote: > > > On Wed, Jun 11, 2014 at 9:47 PM, Sean Dague > wrote: > > Actually swiftclient is one of the biggest offenders

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

On Thu, Jun 12, 2014 at 12:58 PM, Chmouel Boudjnah wrote: > > On Wed, Jun 11, 2014 at 9:47 PM, Sean Dague wrote: > >> 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

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

On 06/12/2014 12:33 AM, Morgan Fainberg wrote: > I’ve been looking over the code for this and it turns out plain old SHA1 > is a bad idea. We recently had a patch land in keystone client and > keystone to let us configure the hashing algorithm used for token > revocation list and the short-token i

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

On Wed, Jun 11, 2014 at 9:47 PM, Sean Dague wrote: > 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 > I'd be happy to fix that but that would make

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

Morgan Fainberg wrote: > I’ve been looking over the code for this and it turns out plain old SHA1 > is a bad idea. We recently had a patch land in keystone client and > keystone to let us configure the hashing algorithm used for token > revocation list and the short-token ids. > > I’ve updated m

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

Fainberg From: Jay Pipes jaypi...@gmail.com Reply: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Date: June 11, 2014 at 12:49:35 To: openstack-dev@lists.openstack.org openstack-dev@lists.openstack.org Subject:  Re: [openstack-dev] masking X-Auth-Token

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

On 06/11/2014 03:01 PM, Sean Dague wrote: 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

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

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

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

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

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

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

[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/neutronc