(Reading time: 4 - 7 minutes)

What is the “secret word” in Joomla used for?

1340 hits Updated: 08 April 2022 Blog

What is the “secret word” in Joomla’s configuration settings used for?

I’m unable to learn about this “secret word” in Joomla:  what is it’s purpose … [and is it] useful for website owner?  Please tell me its complete usage and advantage if you know.forum user, Joomla Forum, 14-Jan-2011

You may be wondering why I dredged up a question asked ten years ago as a preamble to this article.  It’s actually a very good question that has never been really satisfactorily explained in plain English.  For example, if you take some of the “guided tours” of Joomla’s configuration.php fileJoomla 4 Configuration.php file—8-Sep-2021, inmotion.com; A Guided Tour of Joomla's configuration.php File—12-Jun-2019, Joomlashack in one case there is a suggestion that this is displayable in J! 4.x by going to System » Global Configuration » Server » Server (which isn’t true since J! 2.5) and in another case the only information about this setting is that it’s generated when Joomla! is first installed, is not changeable and used “internally” by Joomla! for security purposes; it is true that you cannot change this value using the Global Configuration facility but you can change it by editing the configuration.php file and it’s true that the value is generated when a J! website is created but the internal purposes of \(secret are not explained.  Can you change \)secret or can’t you (and what happens if you do)?  To further confuse the matter, some people have recommended that you should change this value https://www.itoctopus.com/25-joomla-important-tips.

In this article we will discuss one line of code in the file configuration.php (at about line 20) located in the root folder of a J! website.  It looks like something like this:

	public \(secret = 'RndmL3ttrsNumbrs';

What does this line do in Joomla?  As far as I can tell, it doesn’t a lot.  Digging into the Joomla forum, we find this

Joomla uses \)secret for encryption/decryption purposes.  When you look in Joomla’s source code for “secret”, you will find references to “secret” like in /libraries/joomla/utilities/simplecrypt.php forum user, Joomla Forum, 19-May-2012

That sounds like a pretty good explanation except that J! 3.x (and J! 4.x) does not have a file named simplecrypt.php in that directory.  Did this file get moved somewhere since J! 2.5 (when the discussion on the forum took place)?  Yes, the file was relocated to the folder /libraries/legacy/simplecrypt.  So this information doesn’t really explain its purpose.  Furthermore, the method used in that file is deprecated.  In J! 4.x, there is no file named simplecrypt.php anywhere.

A clue to one of its purposes appears in a GitHub discussion.

The security of the site is largely dependent on the quality of \(secret in configuration.php.  This is not visible in any user-facing parts of the application and is calculated with a crypto-safe random string generator which is good news.  Also, changing \)secret immediately changes all tokens, making it a dependable nuclear option if one so wishes. Nicholas Dionysopoulos, GitHub, 5-Nov-2019

The above comment was made in a discussion about the J! 4.x API but the take-out I got from the conversation relates to what happens when you change the value of \(secret—the “nuclear option”. Again, in the past, various commentators on the Joomla forum had mixed opinions about what happens if you change the value of this field:  some people advised that it would prevent everyone from being able to login.  This is not true!  If you change \)secret while you (or an other users) are logged in, you will terminate those sessions and those users will have to login again.  In that sense it’s a “nuclear option” for terminating sessionsWe discussed sessions in a previous article:  How to fix the “failed to start session” error in Joomla.

In summary, I have changed \(secret in the file configuration.php; I have set the value to an empty string and I have even removed the line of code entirelyI would not recommend deleting any lines of code from configuration.php. and I have not seen any real problem in making these changes.  I have not yet found a satisfactory explanation about what \)secret does in J! 3.x or J! 4.x but it probably doesn’t matter and it seems highly unlikely that it causes problems.  If anyone has any other information they wish to share to advance our knowledge they can use the comment form below.

About the author:

has worked in the information technology industry since 1971 and, since retiring from the workforce in 2007, is a website hobbyist specialising in Joomla, a former member of the Kunena project for more than 8 years, and contributor on The Joomla Forum™. The opinions expressed in this article are entirely those of the author. View his profile here.

3 thoughts on “What is the “secret word” in Joomla used for?”

  1. Friday, 08 April 2022 21:59

    oh right. that makes a lot of sense. you dont know what something does and you tested a fraction of joomla's capabilities and conclude that there is no need for it at all and it should be deleted. Get a grip. Do you really think it is there for no purpose at all. Surely everyone knows by now that it is used to provide secure remote access to any joomla web site when providing technical support.

  2. Friday, 08 April 2022 22:34

    Since you are using my name (and my comment software, apparently) on this site I felt obliged to enlighten you on what the $secret is used for and why what you did, even though it doesn't visibly break anything, has screwed up your site's security.

    The $secret value is used as an encryption key, typically using the Joomla\CMS\Crypt\Crypt class — which in turns extends from the Joomla Framework Joomla\Crypt\Crypt class.

    So, where is it used in the Joomla core itself? I will give you some of the spots it's used, you can find the rest by grepping the codebase for ->get('secret'

    • Encrypting the Two Factor Authentication configuration. This means that even if your site has a SQL injection vulnerability which allows exfiltration (but not modification) of arbitrary table data the attacker would not be able to circumvent Two Factor Authentication. See \Joomla\Component\Users\Administrator\Model\UserModel::getOtpConfigEncryptionKey
    • It is used in \Joomla\CMS\Version::generateMediaVersion to create a media version key. Why not just use an MD5 of the CMS version? Because without the secret as a salt it makes fingerprinting your site dead easy, something I have explained ELEVEN YEARS AGO in the Joomla Community Magazine.
    • It is used in \Joomla\CMS\Application\ApplicationHelper::getHash to generate secure hashes — we'll get back to that later.
    • It is used in various places, e.g \Joomla\CMS\Application\SiteApplication::initialiseApp, to handle cookies with secure names. It's a subcase of secure hashing as above. We'll get back to that later.
    • It is used for the API application's token authentication in \PlgApiAuthenticationToken. By removing the secret you are degrading the security of the token authentication from virtually impossible to break to trivially breakable.
    • It is used by the WebAuthn plugin to create secure user IDs. Another case of secure hashing. See \Joomla\Plugin\System\Webauthn\CredentialRepository::getEncryptionKey

    It is already quite obvious that using an empty secret has so far broken the security of your site. And this is not even half as bad as it really is once we talk about secure hashing.

    Joomla uses MD5 or SHA1 sums of otherwise easily guessable information to create cookie names and single use tokens. For example, the session cookie name, the Remember Me secure tokens etc need a fully random and long enough $secret to be truly random; if they are not, their names can be guessed which means that an attacker can fairly easily impersonate you or any other user on your site. At a minimum, they would be able to issue a password reset and try one of the few hundred reset tokens possible for the timespan between sending the request and receiving a reply. With a truly random, long secret word this is no longer a few hundred possible tokens, it's several billions of them making it practically impossible to abuse the password reset feature.

    This becomes even worse when you take into consideration that third party applications also use \Joomla\CMS\Application\ApplicationHelper::getHash or the $secret to create secure hashes. For example, since you are using Akeeba Engage for your comments, remember that all admin URLs are signed so you can take action without being logged in. Well, well, well, how is this done? Right, by using the $secret:

    public static function getToken(string $task, string $email, string $asset_id, int $expires): string
    $signString = $task . '-' . $email . '-' . $asset_id . '-' . $expires;
    $key = Factory::getApplication()->get('secret');

    return hash_hmac('sha1', $signString, $key, false);

    So what does that mean? The signature requires me to know $task (that's the action I am taking), the $email (your email is not a secret!), the $asset_id (I can try using values 0 to 1000 and I'm in) and an arbitrary expiration date which is under my control. Since I know your $key to be an empty string I can now issue 1 to 1000 HTTP requests and publish / unpublish / delete any comment on your site. All your comments are belong to us. Just because you idiotically removed your site's $secret. For the love of $deity, don't do that!

    If you are using LoginGuard for Two Factor Authentication, same deal, we use $secret to protect the configuration. If I can get a dump of #__loginguard_tfa and know that you're using an empty key I can decrypt it in a split second and pwn your sorry butt.


    Now that you done f****d up, Mike, please go to https://www.random.org/passwords/?num=3&len=24&format=html&rnd=new concatenate the three passwords into one big 64 character password and put it into your site's $secret before someone far less kind than me decides to teach you a lesson by hacking you instead of educating you. I can't believe that you not only emptied your secret but proudly told the world you did... This is exactly just as stupid as telling the world that your front door no longer has a key! I'm shaking my head in disbelief...

    1. Saturday, 09 April 2022 06:51

      Thank you very much for your thoughts, Nicholas.  No, I didn’t  break the security of my website by changing the value of $secret to an empty string (and I certainly wasn’t suggesting that people should do this anyway).  If you understand that it’s been difficult for many people to unravel the “secrets” of Joomla’s configuration.php—if these things were well documented and explained then people would not be asking questions—I’ve been experimenting with different values of the $secret variable and I haven’t been able to work out how it’s  used.  I’m sure it’s important but my research hasn’t revealed how it’s used.

      Although I quoted the you on the public record, it was not my intention to quote you out of context and, if I’ve done that, then please accept my apologies.

      Even though I experimented with different values of $secret, I changed it back to its original value.  Therefore, I haven’t done any permanent damage to my test site.  I would never change this variable on a real website (and certainly not on this site that you took the time to provide us with your comments) so everyone can relax that this site is not broken in any way … well, not in any way that I’m aware of.  Everyone can relax.

      I don’t use TFA—it’s unnecessary in my line of work—or third-party extensions such as Akeeba’s LoginGuard.  I have other means of protecting this website from unwelcome attention.  Be that as it may, we can all learn from having a full, frank and exploratory discussion about our Joomla experiences.

      I don’t normally reply to comments written in response to the articles I write.  Out of respect for taking the time to comment, and out of admiration for the wonderful contributions you have made to the J! project, I felt it was important to respond to you in this way.

      Thanks again and best wishes always.

      P.S.  I love Akeeba Engage, BTW.  It’s the best commenting software I’ve found for J! articles.

User Rating: 3 / 5

Star ActiveStar ActiveStar ActiveStar InactiveStar Inactive
Trending now