Support

You made a wrong assumption, that the Master Password feature is a security or authentication feature. It is not. First, let me explain why it is NOT either of them.

In order to come to a point where you need the MP you have to log in to the back-end of the site as a Super Administrator. If you do that and your objective is to disable Admin Tools, you can just as easily go to the Plugin Manager, disable "System - Admin Tools", then go to the Extensions Installer and uninstall Admin Tools. Game over. Protection has gone away. Dumping the database to steal the MP is an unnecessary overkill. Corollary: your most valuable asset is applying Admin Tools' security features to prevent a malicious user from logging in as a Super Administrator in the back-end of your site.

So, what is the MP good for if it's not a security or authentication feature? It's there to keep nosy clients from wrecking havoc on the site you delivered to them. Most usually, we set up a site with the exact .htaccess and WAF configuration required. We don't want the client to go around and play with those settings, due to the unfortunate consequences of such an endeavour. This is where MP comes to play.

Another question is how you can limit who can access Admin Tools? Well, it's called ACL :) In Joomla! 1.6 we use Joomla!'s built-in ACL system. Just click on the "Options" button in the toolbar. In Joomla! 1.5 we have our own ACL system which can be managed by clicking on the "Access Control" button. You can then choose which user has which privileges. Simple and easy.

Regarding your other question, Admin Tools does not store any passwords except the MP. Regarding our other software, Akeeba Backup does store passwords in their original form because they have to be used to authenticate the site against external services, e.g. database servers, FTP servers, Amazon S3, etc. That said, if your server supports mcrypt, Akeeba Backup will use it to encrypt its data with a randomized password created the first time you run the component and stored in a PHP file so that it can not be directly accessed over the web.

It's no my turn to demand you to think the context of the MP and understand why it is not being stored encrypted. Storing it encrypted would require a separate view to set the MP and a separate view to manage the restricted views. This is an overkill considering the context of its use so I decided to favour usability against unnecessary security.

The software is licensed under the GPL so that you are able to modify it. You can study, understand and modify the code. I won't help you with that because code customisation is not included in the support services we provide. We also won't provide support for modified versions of our software. We only provide support for using unmodified versions of our software. If you want to exercise the freedoms granted to you by the GPL you are free to do that, but now you're creating a derivative work which is no longer supported by us.

Side note: if you think that what you're doing is secure, just Google the term "rainbow tables". Or, if you're a little lazy, take a look at this page. Using plain MD5 is just as good as using no encryption at all. Given the MD5 you can very easily come up with an equivalent password from the rainbow table. In order to mitigate RT attacks you need to salt the password before hashing it. Take a look at how Joomla! is doing it since 1.0.11.

Regarding Akeeba Backup, as I said, we encrypt your entire configuration with AES-128 if your server has mcrypt installed. If not, the passwords are stored in cleartext. IMHO, if your server doesn't support mcrypt it's a crappy box anyway, so it's best to dump it and choose a decent host.Back to your question, if you produce MD5 of the passwords which Akeeba Backup needs... well, just try it and you'll see hell breaking loose. The thing is, all passwords stored are not being used to authenticate a user against Akeeba Backup. They are being used to authenticate Akeeba Backup against a remote server. IMPORTANT: we DO NOT have any saying as to how the remote server works!

So, Akeeba Backup needs to have access to the original password, not an irreversible MD5 sum or other hash. Example to help you think about it: if I asked you to give me your FTP credentials and you gave me the MD5 of your password, would I be able to login to your FTP server? No way I could. Likewise, if Akeeba Backup was storing the MD5 hash of your FTP password, would it be able to log in to the remote FTP server and upload the backup archives? Nope. MD5 sums are one-way hash functions. That's why we're using the industry-standard bidirectional AES-128 encryption algorithm in CBC mode to encrypt the configuration data whenever possible.

Many times I ask for SA access on users' sites to fix problems they have with my software which require hands-on access. If I had a fiver every time the username was admin or the password was something trivially guessable I would now be typing on a keyboard whose frame is made of gold and keys made of diamonds :)

As an interesting side note, do you know what is better than a 16 character password? Choosing four random, unrelated words and combining them. For example, "Cockroach Entrenchment Napkin Austerity" would take a few thousand years for a modern supercomputer to crack by brute force. Skew the spelling a bit and throw some special characters and numbers in there to make it unsusceptible to dictionary attacks and you're set. Not bad, huh?

Akeeba Backup has nothing to do with Admin Tools and the Master Password feature of the latter. Akeeba Backup doesn't need to "authenticate" itself against the server. It merely checks if you have adequate rights to perform a backup. And, as I explained, the Master Password does not authenticate anyone to anything. It's a small hurdle, not an authentication procedure. Authentication means a method for proving your identity to an authority. MP does not prove your identity by any means (your username/password pair in Joomla! does). It's a complementary method to authentication, making sure that someone doesn't accidentally use a feature which could kill his site.

Regarding your Akeeba Backup problem, first make sure that you have not modified any of its files. Perform a clean installation of Akeeba Backup if you are not sure. Then, retry backup. If it still fails, please start a new thread and post your Akeeba Backup log file.