I don’t know how this would work.
I am not an expert in these things, but I am not sure how you could ever do what you want.
The reason storing the hash and knowing the salt works for users is because the user enters the password manually when they login, the system hashes it with the salt and compares it with the hash value it has stored. This way the system never knows the actual password and the purpose is for user security. The real password has to be known/entered somewhere.
Even with the idea of mysql userdatabase, you would have to store the user/password for the mysql database somewhere which had read access to the user/passwords you wanted to supply to kibana. which results in the same problem.
If an application was started manually it would be possible to have this password “offline” and only entered at that point, but any service/background startup would not work.
I have used ssl certificates to secure it otherwise, so at least the password it sends over the network isn’t in plaintext as it requires kibana to use the https url.
If you are worried about access to the system this is a larger problem. As even following the search guard examples for securing with tls/ssl you had the passwords for the keystores in the elasticsearch configuration in plaintext.
On Friday, 20 July 2018 10:10:44 UTC-4, th...@jumpsec.com wrote:
I have just successfully installed Searchguard 6.3.0-22.3 (in a self configured docker-elk stack running version 6.3.0 - no other plugins installed, and tbh all the versions don’t matter) and have finally got to the point of getting ready for production, but there is a serious concern that I have which isn’t addressed anywhere else according to my research: where can we store the elasticsearch.user credentials instead of keeping them stored as plaintext inside kibana.yml config e.g. “kibanaserver”. Is there a setting to allow us to store the BCrypt hash in kibana.yml instead? I have tried just giving the hashed value but then the authentication fails, also I fear that the server would then be vulnerable to Pass the Hash type exploits/rainbow tables.
Ideally I would like to have an internal-users database on the Kibana side of the stack to store the hash and salt but I haven’t been able to figure this out for myself yet (e.g. reading credentials from a MySQL database into kibana.yml config file? Seems like overkill…)
Please let me know what people are doing in production to avoid these security issues?