there are about a zillion ways a person familiar with mojoPortal could determine if a site is using mojoPortal and I suspect that is also true of most popular cms systems, blog platforms, forums, image galleries, etc.

If that is important to you and/or your client to really be able to obscure what cms you are using and you know of another platform where it possible for you to really do that then you should probably use that platform for your project.

It is not a goal for this project to provide that level of obscurity and I don't think obscurity offers much in the way of security.

Best,

Joe

As you work on these projects, I do think you should submit your code changes to Joe Audette for consideration. If they are focused, well done, and do not negatively impact existing mojoPortal sites (i.e. all changes are fully-backward compatible, and the upgrade process will not require users to make configuration changes in order to keep using their sites as-is), I'm pretty sure that Joe will give fair consideration to incorporating them into the mojoPortal core. I speak from experience on this, having just made some changes to allow fallback LDAP authentication that will benefit our site and others who want to work the way we do. Having your changes incorporated into the core will also benefit you tremendously, since you won't be left maintaining a dead-end code fork. Since you are so security-conscious, I'm sure you can appreciate how important it is to be able to upgrade as soon as possible when security issues are discovered.

Changes to obscure the CMS type are not very compelling to me, since part of how we give back to mojoPortal is by leaving the "powered by" link on our sites. But I would definitely be interested in seeing what you can come up with for an installation wizard (and hopefully a companion upgrade wizard, since mojoPortal upgrades happen quite often). It would be very nice to have an easier way to manage all of the user.config/web.config keys. And I would find improvements to the search quite welcome as well.

About the community comment, I'll try not to take offense, but you should know that mojoPortal is a bit different than a lot of other open source projects--Joe has literally dedicated his life to this project, now that it is his sole source of income (from add on products, etc.).

Jamie

Before anyone starts working on obscuring the file system paths or a setup wizard they should know that while I said "maybe I would be so impressed with your solution that I would consider it", the reality is that it is highly unlikely that a solution will be proposed that I would accept, I was only saying it is not outside the range of possibility but it is certainly outside the range of "likely". I was trying to be nice.

The most likely outcome is I will not accept it, so consider the possibility that if you fork the code to meet this need you are on your own and maintaining your fork and that will likely be worse in the long run in terms of security if you are not able to get my updates easily.

The reasons why I say it is unlikely is because

1. I was not exagerating when I said there are a zillion ways to determine what cms you are using. I really could spot mojoPortal based on css classes in the markup alone (and many many other ways) so it is fruitless to think you could hide mojoportal by changing some paths.
2. any solution to a complex problem is likely to be a complex solution and complexity is the enemy of security so it seems extremely unlikely that I would accept a lot of complexity to help create obscurity
3. I am fairly confident that if I wanted to I could very easily write a program to guess the cms used at any url by making analysis of the markup and running tests to guess the cms, the presence of markup signatures, the existence of files at certain paths and many other things could be used to create a probability score of which if any well known cms a site is using. One could try and try to obscure it but I bet I could continue to detect it by a variety of methods.

Also it is difficult to take seriously this approach that claims we need this obscurity to improve security from someone who calls himself a "Security Professional" and then in the next sentence suggests a Setup Wizard so that web code can write to the Web.config file which is a very bad idea form a security point of view and I have discussed it here already:

http://www.mojoportal.com/why-custom-features-should-be-installed-by-ftp.aspx

I can say for sure we will not be doing anything to make the web code modify the web.config file in mojoPortal.

Anyway since others chimed in with encouragement of this I thought I should clarify my position so there is no confusion.

Best,

Joe