Support

Hello Stefan,

The thing is that this feature doesn't make your sites much more secure. It merely obscures the point of entry, it doesn't make it more secure. The best way to secure your administrator is applying the following:

• Use the administrator password protection with a username and password different than the one you use for the Super User. This is the MOST efficient anti-brute-force protection! It takes place in the web server itself, long before PHP loads. This can defend your login form against the vast majority of brute force attacks.
• Use the secret URL parameter. It offers the same level of login form obscurity as the changed administrator directory without any of the problems.
• A decent username. Avoid admin, administrator, god, owner, manager or any word combination which can be derived from the domain name and/or one of those easily guessed names.
• A good password. I'm using 40 character passwords with alphanumeric and special characters. They are impossible to remember or guess, which is the whole point. Use a password manager such as LastPass, KeePass, 1Password etc to manage them.
• Enable Two Factor Authentication. Even if someone steals the username and password they will still need your smartphone or your YubiKey to log in. We had this feature in Admin Tools, two years ago we improved it and donated it to the Joomla! project to the benefit of all Joomla! users. Now it's part of Joomla! 3.2 and later.
• If possible, use HTTPS. This doesn't protect the login form against brute force attacks but it does protect you when you're logging in from a public Internet connection. If you're using plain HTTP it's easy for someone to subvert the login information, for example using the WiFi Pineapple.

As for the changed administrator directory we decided to remove it because it cannot be made to work with the vast majority of servers. If a feature cannot be made to work for more than 95% of our clients who can reasonably expect to use it we don't include it. This feature was the #1 cause for support requests and we could not resolve almost any of them – the only ones resolved were the ones where the user forgot to enable the SEF URLs on a supported server, but I can count them on one hand... This meant for us that this feature was a big failure. We did try our damnedest to make it work but it ends up being up to the server configuration and in a way that we cannot even reliably predict and warn users that it will not work (unlike, say, .htaccess Maker where we can very reliably predict when it won't work and warn users in advance). It's OK to fail. It's not OK to pretend that you didn't fail. So we accepted our failure and did the only honest thing we can do: remove the failed feature and tell you the alternatives to get a very secure back-end login form.