← Back to team overview

yahoo-eng-team team mailing list archive

[Bug 1465922] Re: Password visible in clear text in keystone.log when user created and keystone debug logging is enabled

 

The OpenStack VMT currently considers (based on existing precedent)
disclosure of sensitive information in debug-level logging a security
hardening opportunity, and does not issue security advisories for it.
This is class D in our report taxonomy: https://security.openstack.org
/vmt-process.html#incident-report-taxonomy

** Information type changed from Private Security to Public

** Also affects: ossa
   Importance: Undecided
       Status: New

** Changed in: ossa
       Status: New => Won't Fix

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Keystone.
https://bugs.launchpad.net/bugs/1465922

Title:
  Password visible in clear text in keystone.log when user created and
  keystone debug logging is enabled

Status in OpenStack Identity (Keystone):
  New
Status in OpenStack Security Advisories:
  Won't Fix

Bug description:
  grep CLEARTEXTPASSWORD keystone.log

  2015-06-16 06:44:39.770 20986 DEBUG keystone.common.controller [-]
  RBAC: Authorizing identity:create_user(user={u'domain_id': u'default',
  u'password': u'CLEARTEXTPASSWORD', u'enabled': True,
  u'default_project_id': u'0175b43419064ae38c4b74006baaeb8d', u'name':
  u'DermotJ'}) _build_policy_check_credentials /usr/lib/python2.7/site-
  packages/keystone/common/controller.py:57

  Issue code:
  https://github.com/openstack/keystone/blob/master/keystone/common/controller.py#L57

      LOG.debug('RBAC: Authorizing %(action)s(%(kwargs)s)', {
          'action': action,
          'kwargs': ', '.join(['%s=%s' % (k, kwargs[k]) for k in kwargs])})

  Shadow the values of sensitive fields like 'password' by some
  meaningless garbled text like "XXXXX" is one way to fix.

  Well, in addition to this, I think we should never pass the 'password'
  with its original value along the code and save it in any persistence,
  instead we should convert it to a strong hash value as early as
  possible. With the help of a good hash system, we never have to need
  the original value of the password, right?

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1465922/+subscriptions