Security and privacy

Can think of only one instance in which database credentials could be 'exposed' ... more like 'acquired remotely' by un-authorized access.   Did some 'ethical/whitehat hacking' once and discovered this ...

IF php is broken, any index.php file doesn't render pre-hypertext processed, but what appears to be a mix of html and confused state.  Apache server treats .php files as text ... doesn't pre-hypertext process them.   So, someone could acquire config.php file using any command line app like wget, curl, etc.. 

Example wget http://site/config.php https:// could also be used.  Nothing to stop that.  Only diff in those two is http not encripted when data sent over the wire and in https the data is encripted but the data has to be un-encripited on the rec. end.  Anyone using a browser pointed to config.php won't display anything cause there's nothing a browser would understand.   But, the file would be in cache.

Once config.php is acquired one can open it in a text file editor.  One will see then, the DB server, the DB, DB user, DB password for that user.  **IF** the installer used the same user as the root user for the operating system with the same password for the config of MySQL, then that's a big hole.  And, **IF** ssh is opened on server with no restrictions as to IP address, then anyone could use ssh, use the root user name, with root password found in the config.php file to gain shell access as the root user.

So, never use root as DB user.  Never use the same password for the shell root user in the config of MySQL.  And when one sets up the admin user in Moodle, don't use root, and don't use the root users password.

'spirit of sharing' ... and 'whitehat hacking',

Ken

Database details in Moodle are stored in the $CFG variable, and to dump this data you would have to do it intentionally. Moodle itself is well hardened against people uploading PHP and trying to execute it - but the server admins also need to set their permissions on web directories correctly to aid in protecting against this too.

Best practice for any Production web application (not Moodle specific) states that you should have all debugging messages and server errors hidden from display in the browser and redirected to a text file (via PHP configuration options) should they occur.

That way if an error arises no potentially useful data is given to an unknown user.

Ken's example of a mis-configured PHP server is possible, however unlikely, and certainly not the norm.

HTTPS does not change any of this as this only protects data on the wire from outside snooping.

Without being able to inject arbitrary PHP code into Moodle (so that $CFG variables could be printed) it's unlikely. 

However, consider that Moodle is a pluggable system and we cannot speak for the quality of all plugins you might have recklessly installed on your site

So, my advice is that you should set up your database in such a way that you could copy your database credentials right here and not care because your DB is properly firewalled. You shouldn't be allowing access to those ports from outside of your organisation and you shouldn't be using the credentials for anything else.