Support

Hi Simon,

No need to wonder when we have thorough documentation. Here's what I'm writing in the docs:

Normally, you can access your site's administrator area using a URL similar to http://www.example.com/administrator. Potential hackers already know that and will try to access your site's administrator area the same way. From that point they can try to brute force their way in (guess your username and password) or simply use the fact that an administrator area exists to deduce that your site is running Joomla! and attack it. By entering a word here, you are required to include it as a URL parameter in order to access your administrator area. For instance, if you enter the word test here you will only be able to access your site's administrator area with a URL similar to http://www.example.com/administrator?test . All other attempts to access the administrator area will be redirected to the site's home page.

Well, as the passage I copied reads: All other attempts to access the administrator area will be redirected to the site's home page. This means that if they do not supply a secret word or they supply the wrong secret word they will be redirected to your site's homepage. This doesn't allow them to understand if you have a Joomla! site or not.

I would argue that if someone want to figure out if you're using Joomla! he can do so very easily. For instance, I use K2 and K2 adds its own CSS / Javascript on the page. It's trivial for an attacker to look for K2-enabled sites and figure out that they are using Joomla!. The most important protection offered by the secret word feature is that they can not brute-force your Super Administrator password.

I know, site security is neither the most fun nor the most easily understandable topic, but it's certainly a very interesting and essential one! Keep on reading and educating yourself :)

There is a reason why I have not implemented such a feature: false positives :D Just the fact that a file changed means nothing, especially if you just upgraded a crapload of extensions. Moreover, false positives work to your disadvantage. You know that a lot of false positives will be thrown after you update a few extensions. What about someone hacking you in the meantime? You never notice. Bummer!

Also, a file change feature means that you are wasting a ton of site resources. There are two ways to check files for modifications: file timestamps and file checksums. The former method is very easy to forge, so you can be hacked without getting a warning. So, you have to rely on checksums. However, calculating checksums requires a lot of resources and db space to store them. It's essentially like taking a backup of your site as far as resource usage is concerned. But if you are to go that route then you'd ideally want the code to produce a diff of the files or, better, try to "figure out" if the difference carries any risk (e.g. base64 encoded variables, use of "suspicious" functions like exec, email and ftp, accessing off-site files like /etc/passwd and so on) and notify you. This is something that I am considering for version 2.2 of Admin Tools, but it will be a HUGE resource drain and will not work for every site.

Instead, I recommend a different approach for now. Take daily backups. Every time you upgrade something, take a new backup before and after the upgrade. Then, compare each backup with its previous backup using Akeeba SiteDiff. If there are added or modified files (but not between pre-update and post-upgrade backups) you need to worry.

I guess you'll just have to wait for the Admin Tools 2.2 then :)

Well, that feature is going to be added and you'll be able to run with exactly two different ways: 1. manually, from the back-end; and 2. if you set up a CRON job. So there will be nothing to turn on or off. You can either set up a CRON job or not, we're not going to do that for you anyway :)