After a week of playing with various CMS implementations I have settled on XOOPS which provided the easiest, most intuitive admin and customization of all I played with.

As I was doing some side-by-side comparisons, I had XOOPS buried down in a subdirectory, and as I have now select it as the one I want to go live with, I'm in the process of (literally as I type this) moving the files up to root. I believe all I have to do is change the path info in mainfile.php to make this work (if that's not the case, I'll be posting for help ).

Anyway, in looking at the mainfile.php I couldn't help but notice that the database login and password are sitting there in plain text. Can anyone in the community talk me in off the ledge; can someone please tell me why this is not a gaping security hole?

Seems mighty dangerous to me .....

JP

check this out: http://xoops-tips.com/modules/news/article.php?storyid=1

also make sure mainfile permissions chmod 444

Thanks for the link.

Certainly better, but not ideal. 60% of all attacks happen within the firewall (i.e. employees or other "trusted" resources).

Critical information like login IDs and passwords should be encrypted no matter where they are kept. The hosting company I use does not allow their support staff to know my database ID's/passwords. They can look at my files however, and - oops!! - there they are in plain view.

As a consultant, it would now be difficult for me to recommend XOOPS to a client for a mission-critical site for this very reason.

I hope to see this in a future release. XOOPS is an excellent CMS; there are others that are not as nice that have this feature (postNuke comes to mind).

This is in no way a criticisim of the product or the development team; as I said in my original post, XOOPS stood out head and shoulders above other CMS implementaions I played with. I just have a nagging concern about security now, and I hope to see it addressed at some point.

Thanks again for your timely response!!

JP

You have a good point I think. I have been wondering on how this could be handled, but since I am not too much of an encryption expert I had to stop myself before I'd knock myself down

Apart from this being a feature request for future releases, does anyone have an idea on how to implement this?

Regards,

Martijn

Besides the tips given here there are more things to do.
I like to prevent attempts to even try pulling the file in a browser.


Order allow,deny
Deny from all


This will log a Forbidden error in your server logs.

Another way is to encrypt the file itself. Most of the PHP addon accelerators/compilers have an encryption feature. Typically these are used for commercial applications so that the customer can't see the code. Also handy for sensitive files like this.

The file becomes unreadable except to the webserver and only if the server is using the same engine. Zend products and MMCache are two that I've tried. Since you rarely need to edit the file this is a useful trick. You store the raw file somewhere safe so you can edit and reencrypt it later.

I don't see this as much different than an SSL key file that also must be protected. If your server gets rooted you have other problems.

I think encryption with an encryption program is good. It requires manual encryption after the installation process. Download mainfile.php, encrypt it and upload the encrypted mainfile.php together with the encryption file (if required).

Do you think it is possible to encrypt the file automatically during installation, without needing to perform this manual procedure after the installation?

Regards,

Martijn