Open Stack

Well, there's not necessarily a reason to avoid masking sensitive data
in debug level logs as a security hardening measure, we just have enough
cases of this already in various places along with documentation saying
not to disclose debug logs to untrusted parties that we don't issue
security advisories when yet another is discovered.

-- 
You received this bug notification because you are a member of OpenStack
Security, which is subscribed to OpenStack.
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):
  Won't Fix
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