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

[Simon Reinkemeier]

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?

[Morgan Fainberg (mdrnstm)]

The LDAP backend does not support writes anymore (read-only) and relies on the LDAP server to handle password checking (via bind). Keystone handles the password hashing so that we can control the validation of the password. We have some (in some cases unfortunate) limitations on what the password hash can actually be (length wise). As long as keystone has to maintain what hashes and length (etc) it can support I am inclined to say that this is not really in line with our direction.

With that said, I am willing to consider this change if you provide some more information on how you would ensure that the password conforms to the limitations we have in place:

1) Types of supported hash(es).
2) Length for the storage system (SQL column)
3) Input and how this is communicated via the API (is it a 'hashed_password' element in the JSON passed on creation?)
4) Errors passed back to the user creating the user if something is not correct with the hashed password

I would also like to know if you've thought through the risk assessment of allowing pre-hashed passwords and how that can impact the safety of the password. Consider that the number of rounds used increases over time (naturally) as the CPU power increases (and GPU power). This is handled in keystone's implementation of hashing and that we lean on passlib. This means if passlib increases/changes the default we also increase/change the default (subject to change in any given deployment).

Similar to the above question, salt impacts the password hash size and complexity, are there additional concerns on that front.

Finally, keep in mind that password hashes should be kept in the strictest confidence, if a hash is exposed to the world, I would treat that hash (and unhashed password) as insecure. This is a very strict view, but with the modern password cracking technology a hash is often much less secure than expected.

In short, please answer the above questions and mark this bug back to "new" status (I'm marking incomplete so we can have those answers). I'm willing to accept the RFE as long as we've answered those data points and we have clear documentation covering those answers submitted with the code.

[Simon Reinkemeier (simonre)]

Hi Morgan,
thanks for your reply! We had some internal discussion in our team and came up with these replies to your questions:
1. The types of supported hashes should be all suported hashers mentioned in SUPPORTED_HASHERS in keystone/common/password_hashing.py (validation is looking up the ident and using the hashers from_string option to check for validity).
2. The hashes should be stored in the same column as the server generated hashes.
3. I would suggest providing a separate field which is exclusive-or with the normal password field. The field would be called hashed_password or password_hash to match the current database column.
4. If something isn't right, an exception of some kind should be thrown. This could be something like a PasswordRequirementsValidationError.

In response to your other points: The main usecase we were thinking about here is automatic provisioning of admin users. This feature isn't meant for the actual end users so I'd say ensuring the safety of the password would be up to the admin setting up the OpenStack instance.

[Morgan Fainberg (mdrnstm)]

As a note, I am willing to consider this feature add, however, keep in mind the most we can *ever* validate is that the hashed values conform to the known python passlib format of

    $<ident>$<metadata>$<hash>

That said, if a pre-hashed password is passed in, there will be zero way for us to validate the password is good / usable. I am inclined to say this is going to be complex and prone to errors when used. If an API is very prone to errors it is likely going to generate a number of bugs/concerns that we'll need to field.

I'd like the other keystone cores to weigh in before we accept this additional functionality.

[Morgan Fainberg (mdrnstm)]

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.