-
Notifications
You must be signed in to change notification settings - Fork 25.6k
Closed
Labels
:Security/AuthenticationLogging in, Usernames/passwords, Realms (Native/LDAP/AD/SAML/PKI/etc)Logging in, Usernames/passwords, Realms (Native/LDAP/AD/SAML/PKI/etc)>enhancement
Description
The Put User API currently accepts a password_hash as an alternative to password, when creating or updating a user.
We don't document this, nor do we validate that the hash being stored is supported by the cluster.
We should:
- Add validation in the Put User action that the incoming hash is one we understand (and not
NOOP). SeeHasher.resolveFromHash - Add tests for this
- Add it to the API documentation
The use cases for using hashed passwords in the API are:
- replicating users (and passwords) from other stores (or other clusters) that support compatible hashing schemes.
- improved security in automation tools (e.g. ansible) - the automation scripts can store a hashed password rather than a clear text one
- extreme end-to-end security in user setup (ES never sees the clear text password)
- efficiency in bulk user setup. Password hashing is one of the slowest parts of user creation. This can offload that work to the client.
Metadata
Metadata
Assignees
Labels
:Security/AuthenticationLogging in, Usernames/passwords, Realms (Native/LDAP/AD/SAML/PKI/etc)Logging in, Usernames/passwords, Realms (Native/LDAP/AD/SAML/PKI/etc)>enhancement