Dolibarr is unable to encrypt the database password as recommended

[JOduMonT]

In the dolibarr dashboard, under Setup -> Security -> Password

at the bottom of the page, under Parameters
if I activate the Encrypt database password stored in php.INI, which is strongly recommended to activate this option
Dolibarr stop working.

My impression is Dolibarr don't have access or the right to write into the php.ini file.

[nebulon]

@JOduMonT thanks for the info and research. The encrypted password handling in dolibarr as described does not make too much sense for us, since the password might change during package update, depending on the database addon thus it always have to be fetched freshly. Further it will always be present in the app's environment as injected into the container.

For phpinfo() I am not sure how this is an attack angle, since if one is able to inject php code to run phpinfo() the attacker might as well just simply dump the env variables manually.

[JOduMonT]

I found this info

1. The password is encrypted. We extend the PDO class to include logic for decrypting the password. If someone reads the code where we establish a connection, it won’t be obvious that the connection is being established with an encrypted password and not the password itself.
2. The encrypted password is moved from the global variables into a private variable The application does this immediately to reduce the window that the value is available in the global space.
3. phpinfo() is disabled. PHPInfo is an easy target to get an overview of everything, including environment variables.

So how to

• disable phpinfo to not being able to overview the variables
• pass the password as a private variable

[nebulon]

@JOduMonT thanks for the info and research. The encrypted password handling in dolibarr as described does not make too much sense for us, since the password might change during package update, depending on the database addon thus it always have to be fetched freshly. Further it will always be present in the app's environment as injected into the container.

For phpinfo() I am not sure how this is an attack angle, since if one is able to inject php code to run phpinfo() the attacker might as well just simply dump the env variables manually.