Config.php password protection

Onlyme

Active member
Is there any way I can encrypt the mysql password in config.php. I'm trying to avoid anything being displayed in plain text.

I don't want to reinstall the whole server to full encryption, the home is encrypted. The only password I have in plain text now is config.php.

Can i do anything about it?
 
I had the same thought when I was changing admin and service account passwords a few weeks ago but haven't pursued it further yet.
 
I had the same thought when I was changing admin and service account passwords a few weeks ago but haven't pursued it further yet.
If anyone gets access to that they can dump the database. Makes sense it being encrypted in some way.

Hope there's a solution :)
 
Is there any way I can encrypt the mysql password in config.php. I'm trying to avoid anything being displayed in plain text.

I don't want to reinstall the whole server to full encryption, the home is encrypted. The only password I have in plain text now is config.php.

Can i do anything about it?

I'm pretty sure the MySQL client libraries that are used by PHP do not support passing an encrypted password to MySQL - they must be sent in plain text.

If anyone gets access to that they can dump the database. Makes sense it being encrypted in some way.

Hope there's a solution :)

If anyone gets access to read your config.php, you've got much bigger problems on your hands.

I have my config.php file owned by root with a group belonging to my web server. It is then chmod 640 so root can read/write while the web server can only read.

To be able to read the contents, someone would either need to A) be able to log in as root, and if they can - they can do anything on your sever anyway, or B) get control over the web server and run arbitrary scripts including those which can read the contents of arbitrary files on the server. Again, once they can do that, you've got bigger issues on your hands.

The important thing is that the config file is not world readable to ensure that if someone was to gain access to your web server using a user other than root or your web server, then they wouldn't be able to read the config.

Ideally, XenForo devs should move to using environment variables to store environment-specific configuration - https://github.com/vlucas/phpdotenv or https://symfony.com/components/Dotenv have become the standard for other frameworks.

That being said, it makes less sense to do so in XenForo given the structure of the application. You'd really need to have a separate public directory as the web root which involves a major change to the XenForo directory structure.

The main point of .env files is to have a simple standard location for environment-specific configuration so that you don't need to check that information into source control when doing automated deployments. Given people don't generally do automated deployments of XenForo, the benefit is minimal.

In the meantime, here is what you should do:
  • ensure that your operating system is secure and patched regularly
  • ensure that your web server stack is patched regularly and correctly configured
  • ensure that you are running the latest version of XenForo
  • secure your config.php file as tightly as you can (ie read only to the web server, not readable to anyone else)
  • watch out for 3rd party addons - there may be vulnerabilities introduced, only run addons from sources you trust
 
Yeah, that's definitely helpful. I live in a Windows world normally so some of the Unix/Linux stuff is still rather new to me.

n the meantime, here is what you should do:
  • ensure that your operating system is secure and patched regularly
  • ensure that your web server stack is patched regularly and correctly configured
  • ensure that you are running the latest version of XenForo
  • secure your config.php file as tightly as you can (ie read only to the web server, not readable to anyone else)
  • watch out for 3rd party addons - there may be vulnerabilities introduced, only run addons from sources you trust

First two aren't really my responsibility since I am in shared hosting and that isn't likely to change (board is too small to bother with a dedicated server)

Third I am definitely keeping on top of

Four I will need to investigate and I thank you for the info you provide on the subject

Five I only have one and I have yet to hear of any security issues with it (Jaxel's Xenporta).

So thanks for that post. It's a good one.
 
I'm pretty sure the MySQL client libraries that are used by PHP do not support passing an encrypted password to MySQL - they must be sent in plain text.



If anyone gets access to read your config.php, you've got much bigger problems on your hands.

I have my config.php file owned by root with a group belonging to my web server. It is then chmod 640 so root can read/write while the web server can only read.

To be able to read the contents, someone would either need to A) be able to log in as root, and if they can - they can do anything on your sever anyway, or B) get control over the web server and run arbitrary scripts including those which can read the contents of arbitrary files on the server. Again, once they can do that, you've got bigger issues on your hands.

The important thing is that the config file is not world readable to ensure that if someone was to gain access to your web server using a user other than root or your web server, then they wouldn't be able to read the config.

Ideally, XenForo devs should move to using environment variables to store environment-specific configuration - https://github.com/vlucas/phpdotenv or https://symfony.com/components/Dotenv have become the standard for other frameworks.

That being said, it makes less sense to do so in XenForo given the structure of the application. You'd really need to have a separate public directory as the web root which involves a major change to the XenForo directory structure.

The main point of .env files is to have a simple standard location for environment-specific configuration so that you don't need to check that information into source control when doing automated deployments. Given people don't generally do automated deployments of XenForo, the benefit is minimal.

In the meantime, here is what you should do:
  • ensure that your operating system is secure and patched regularly
  • ensure that your web server stack is patched regularly and correctly configured
  • ensure that you are running the latest version of XenForo
  • secure your config.php file as tightly as you can (ie read only to the web server, not readable to anyone else)
  • watch out for 3rd party addons - there may be vulnerabilities introduced, only run addons from sources you trust
^ this! I was going to reply to this topic but @Sim pretty much covered the topic.
 
  • Like
Reactions: Sim
Being able to access the core files would 100% be an issue, However, the OP is totally right. This should not be stored unhashed.

It was also mentioned that MySQL cant handle a hashed password, this is untrue thankfully, there are several ways of doing so - Wordpress has used this process since day one.
 
It was also mentioned that MySQL cant handle a hashed password, this is untrue thankfully, there are several ways of doing so - Wordpress has used this process since day one.

Exactly how can MySQL "handle a hashed password"?

WordPress stores its MySQL password in wp-config.php in plain text too, just like XenForo does.

I think you might be confusing the user passwords that people use to log in to XenForo or WordPress - those passwords are stored in the MySQL database in a hashed form in both XenForo and WordPress.

The database password used by PHP to connect to MySQL must be stored in plain text.
 
Top Bottom