yahoo-eng-team team mailing list archive

[Morgan Fainberg <morgan.fainberg@xxxxxxxxx>]

Discussed this with the Keystone core team and we came to the following
conclusions:

* This is prone to errors. It is easy to create an unusable password and
short of also submitting the plaintext password keystone can't ensure
the hash, ident, and metadata is sane.

* This doesn't meaningfully reduce the surface area of attack. Many CMS
tools have integrations with things such as Vault. This prevents the
need to store plaintext passwords for CMS purposes. For consumers of the
API, they still need access to the plaintext password form. The target
is equally split between the scripts/humans/tools accessing the API as
Keystone's create user mechanism. The create_user API is the least
common use of the password. If the users/scripts/tools are using vault
(or similar tools), the CMS to configure keystone should also lean on
those tools.

Generally keystone does not trust externally supplied information it
historically has considered itself authoritative for.

The alternative options that readily come to mind are:

* Deploy LDAP and manage passwords directly in LDAP / separate from
Keystone.

* Deploy an use a tool such as Vault for housing the passwords that both
consumers and CMS would use for creation/maintenance.


At this time I'm marking this as Invalid as it doesn't align with the direction of the project. 

** Changed in: keystone
       Status: New => Invalid

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Identity (keystone).
https://bugs.launchpad.net/bugs/1802136

Title:
  RFE: Keystone SQL backend (and `user_create` API) should support
  prehashed passwords

Status in OpenStack Identity (keystone):
  Invalid

Bug description:
  Keystone should allow pre-hashed passwords at user creation. This
  change would allow passwords to be stored in scripts without storing
  them in plaintext. This would improve security

  The same report was filed for the LDAP backend here:
  https://bugs.launchpad.net/keystone/+bug/1400443

  It was refused because there are various ways this can go wrong with
  LDAP. Would this change get accepted if I implemented it for the SQL
  backend or is there anything wrong with this suggestion?

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