MeshCentral icon indicating copy to clipboard operation
MeshCentral copied to clipboard

LDAP Account connexion password protection (from #4415)

Open lodiabloc opened this issue 2 years ago • 4 comments

Hello

Is your feature request related to a problem? Please describe. Actually an domain user account and password is writed as plaintext in the config file that could be a security issue on some case

Describe the solution you'd like I suggest to keep alive a administrator local account like "LDAP-admin" and we can login to meshcentral webpage with this special account to provide the LDAP credential (for renew or setup) and meshcentral store it encrypted in this internal database this page can also allow to try the ldap connexion with debug output

Describe alternatives you've considered If the host who run Meshcentral is member of the domain, we can use the Users account who run Meshcentral services as credential to do the Query

Additional context Open new issue for this one as asked in #4415

Thanks you in advance.

lodiabloc avatar Aug 22 '22 06:08 lodiabloc

I second this enhancement - Storing passwords in plain text is bad idea. I would suggest making a LDAP Section under the My Server Tab where you can store the LDAP User Connection Info (read from the config.json), with a password box to change/update the password and store in the DB. Doing it here and being available, you can setup the password ahead of time and just need a string to throw into json so it knows the pw is embedded into DB instead of plain text.

kberrylst avatar Aug 22 '22 23:08 kberrylst

I want to look at this a different way. There are a lot of things in the config.json that are confidential and so, I want to protect the entire config.json. One idea was to use HashiCorp Vault to store the config.json and this has been implemented a long time ago, but I have not tried it in years.

The problem I keep running into is that if I encrypt a secret in the database or in a file, where do I store the password used to decrypt that? Said otherwise, where do I store the "root" secret?

Also, is storing the secret in the database in plain text much better than storing it in the config.json? Could that be in fact worst? I have a way to store the config.json in the database. You have a small config.json that connects MeshCentral to the DB, and then I have support for pulling all "meshcentral-data" files from the data including the real config.json.

Ylianst avatar Aug 23 '22 00:08 Ylianst

I'm not specialist on certificate/asymetric encryption but I have one idea (not sure if feseable)

  • we generate a public/private key pair and store it on OS certificate/key manager
  • we configure the OS certificate/key manager to limit access to the private key only at meshcentral process
  • we encrypt the db and config file with the public key and meshcentral use the private one to decrypt it and use it.

lodiabloc avatar Aug 23 '22 09:08 lodiabloc

The only thing I can look at is how other web apps would work. You don't want the password in a webfacing configuration file, or a file that the process is running the app has access to.

For Example, in IIS, you would store the password in the web.config file which would be outside of the sites directory. The process running the webserver would have access to the web.config, but the site running within its Application Pool wouldn't. The App Pool would also not have direct traversal access to the password if you were trying to browse to it thus since the password is stored outside of the App, and cannot be directly obtained by the App, its more secure.

An intermediary fix would be to run the password thru a hash process so that the password isn't plain text in the config, someone would have to dig into the hashing code to determine the secret sauce to reverse the password, you might be able to store the salt in the db used to obfuscate the process some.

My assumption was the DB was safer as it may not be on the same system, or that its only accessible via local host and local processes, but if Mesh web interface was compromised, then its safe to assume commands could be invoked against the DB to retrieve the password and hash anyways.

kberrylst avatar Aug 23 '22 15:08 kberrylst