RFE: Keystone SQL backend (and `user_create` API) should support prehashed passwords
Bug #1802136 reported by
Simon Reinkemeier
This bug affects 1 person
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
OpenStack Identity (keystone) |
Invalid
|
Undecided
|
Unassigned |
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:/
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?
summary: |
- Keystone SQL backend should support prehashed passwords + RFE: Keystone SQL backend should support prehashed passwords |
summary: |
- RFE: Keystone SQL backend should support prehashed passwords + RFE: Keystone SQL backend (and API) should support prehashed passwords |
summary: |
- RFE: Keystone SQL backend (and API) should support prehashed passwords + RFE: Keystone SQL backend (and `user_create` API) should support + prehashed passwords |
To post a comment you must log in.
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.