Is there any way to unhash a hashed BindDN password

[bfaber]

Let's say I needed to restore the password. How hard would it be to do that?

[jonasmeier]

As said above:

If you can access the splunk.secret i.e. because you have console access, it's very easy and public knowledge. Posted several time in other places  i.e. https://community.splunk.com/t5/Splunk-Search/How-to-get-the-plain-text-of-pass4Symmkey/m-p/482645

If you don't have access to splunk.secret: As hard as it is to crack an encryption algo or brute force a hopefully not weak password.

[araitz · Accepted solution]

Splunk is not your password repository, right? Thus, there is no compelling reason to reverse the BindDN password. If you have lost the password, change it in LDAP, type it in to authentication.conf, and restart splunkd. We will rehash it for you 😄

If this is really about security, then the game is probably over once someone has splunk.secret.

But let's pretend that you are a bad guy, you have splunk.secret and the bindDN password string from authentication.conf somehow, but for some reason nothing else (such as the privileges to read splunk.secret, which is chmod 400 by default). Let's also assume you have a working knowledge of common encryption schemes.

Given the above mixed with a strong sense of curiosity and determination (which most 'good' bad guys have), with a lot of trial and error you could certainly get the bind DN password from the password string in authentication.conf.

However, back to being a 'good' good guy, I bet you are practicing the principle of least privilege, and your bind user only has read access on the directory (let alone that anonymous bind has been disabled on your directory and that you are using LDAP-S to query it, right?). Also, I bet you are indexing your LDAP logs to look for queries from suspicious or rarely seen IP addresses.

Thus, even in this doomsday scenario, the most damage done is that the bad guy can enumerate your directory.

[gkanapathy]

Of course it can be done, since the Splunk server does it. However, I think we'd prefer not to publish this unnecessarily. It would be helpful to understand the use case. Is the security audit asking you to reconstitute the password, or it is trying to determine how difficult it would be to do so? If it is the latter, then it is safe to say that with the splunk.secret file, the hashed password (from the authentication.conf file), and the knowledge of the encryption scheme, decryption would be a simple operation, since the password is encrypted using the splunk.secret as the passphrase.

[gkanapathy]

Of course it can be done, since the Splunk server does it. However, we'd prefer not to publish this unnecessarily. Again, I guess I would like to understand the use case. Is the security audit asking you to reconstitute the password, or it is trying to determine how difficult it would be to do so? If it is the latter, with the splunk.secret, the hash, and the knowledge of the hashing scheme, decryption would be trivial.

[bfaber]

I am not sure I believe this explanation. The BINDDN password should be used to log into the LDAP server. It will be decrypted and presented to LDAP without the user having to do anything. It's not a unix 'crypt' style cipher that requires an additional datum (the user entered password) to decrypt.

[smisplunk]

In general, the hashes are one-way. You'd have to throw the dictionary at it (using the same hash algorithm) and see if the result matches the stored secret. In other words, "very difficult" (or very time consuming). Far better to simply reset it. If the question is "hey, this file on disk has the (hashed) password, can someone break in?", then the answer to that is also "very difficult".

[bfaber]

This came up as part of a security audit. I have the server's $SPLUNK_HOME/etc/auth/splunk.secret. How difficult would it be to reconstitute the password?

[gkanapathy]

Could you explain why you'd want to do this, rather than simply re-setting the password to something that you know?