The “Authentication Method” field seems to make little sense

[nikosdion]

There is a new “Authentication Method” field in the user profile but it's undocumented, unintuitive, unclear and appears to lack practical sense.

First of all, it seems to disable Joomla's Two Factor Authentication if the authentication plugin used is anything other than Joomla. This makes no sense. It is perfectly possible that I want to validate a user's username and password against an LDAP server but also let them use Two Factor Authentication for accessing the site. As it is, this feature reduces the security of people using LDAP — or any other pluggable authentication method — unless they use a third party Two Step Verification solution such as LoginGuard.

Moreover, this new option disregards the existence of WebAuthn and any other add-on authentication method which is NOT an authentication group plugin. The reason we did that in 4.0 was to allow non-password authentication methods. This feature, as implemented, makes no sense because it does not, in fact, let me disable Joomla's password authentication and only use WebAuthn. It's really funny because I was having that discussion with a JCM author earlier today...

At the very least, we'd need to query both authentication and system plugins in the Joomla\Component\Users\Administrator\Field\PrimaryauthprovidersField. We'd also need to implement the Joomla\CMS\Authentication\ProviderAwareAuthenticationPluginInterface in the WebAuthn plugin along with a provider check in the login method and publicise that instruction for all 3PDs making non-password plugins, like yours truly.

Finally, to actually make this sensible and usable, it should be a multiple choice selection, not a single entry. As a very realistic example, I want to log into my site using either WebAuthn or my GitHub account — both implemented as system plugins — but not with a username and password at all. This feature does not let me do that. Having one and only one authentication method could have probably made sense 10 to 15 years ago, but not anymore. People prefer using social media to log into sites and the next few years everyone and their dog will be using WebAuthn with platform authenticators. Having Joomla let users ONLY select a password-based authentication method is, not to put too fine a point on it, anachronistic if not outright asinine.

Frankly, this is the kind of feature that should not be handled by the security team alone. It's not a feature which benefits from being shrouded in secrecy as in nobody will compromise a site by being aware of the development of this optional feature! The proof to what I just said is that nobody thought of these very obvious points, something which would have easily been addressed had there been public discourse before its implementation!

CC @bembelimen and @roland-d as the release leads for the current and the next CMS version, @SniperSister as the only JSST person whose GitHub handle I know.

[brianteeman]

lets not mention semantic versioning either

[brianteeman]

If there is going to be a description then it should actually mean something. As it stand I have no idea what it means but as the default is for it to be none that sounds like there is no authentication taking place.

[brianteeman]

We have another field also called Authentication Method but with different options.

[nikosdion]

@brianteeman The only thing that's not affected is SemVer 😂 There is no b/c break (the database schema has never been considered part of the API in Joomla and even if it did, something optional was added so nothing breaks b/c). Code-wise, existing accounts continue working as they did, existing 3PD authentication plugins also work exactly as they did (albeit they do not appear in the dropdown because of the missing interface).

I do agree that None makes no sense in the context of the field label. “No preference” would be a better fit. Even the label is nonsense. Something like “Forced authentication method” would make far more sense considering how this feature is implemented.

I see the seeds of a good idea in it — as I said, I was actually discussing how something like this should be implemented with a Joomla Community Magazine author this morning — but the implementation is so far off the mark that it makes Star Wars' Stormtroopers look like sharpshooters!

[nikosdion]

@brianteeman

We have another field also called Authentication Method but with different options.

Joomla. Consistency. Pick one, mate.

[brianteeman]

@brianteeman The only thing that's not affected is SemVer 😂 There is no b/c break (the database schema has never been considered part of the API in Joomla and even if it did, something optional was added so nothing breaks b/c). Code-wise, existing accounts continue working as they did, existing 3PD authentication plugins also work exactly as they did (albeit they do not appear in the dropdown because of the missing interface).

As you know semver is not just about b/c it also governs new functionality. For me this constitues that. As its a disruptive change.

Fun fact. Setup yubikey on 4.1 in the two factor auth tab of the user account. Then upgrade joomla to 4.1.1 and watch the tab disapear so you cannot disable the two factor plugin for that user. Log out. Go back to the user account. The tfa tab is back

[brianteeman]

OMG what a clusterfck I need to step away from the computer before I try to climb through the screen and smack someone with a clue bat

[nikosdion]

@brianteeman Don't get me started. Scrutiny is something that only happens when I am contributing a feature. When the leadership contributes a feature zero flying fucks are given.

I have been trying to drag this CMS kicking and screaming into modern user login methods and account security for twelve years. And now it's back to the Dark Age just because leadership doesn't understand the subject matter of login security, does not understand how the product is used and can't be arsed to ask someone, ANYONE, who knows a thing or two about both of these very important areas.

I am stepping away from the computer before I explode.

[PhilETaylor]

September 2020...

These changes were made by the JSST to fix SEVERAL Security Issues reported by me almost 19 months ago - Its taken them that long to address them, and still the root issues are NOT resolved.

October 2020 I fully explained to the JSST how 2fa is BYPASSED when using auth plugins.

Even this month, I tried to warn them... and was ignored... I was provided the patch on March 3rd to review and I gave it a very bad review, the patch did not apply cleanly so I was only able to guess and review the code rather than the implementation. It was not fit for purpose and did not address the multiple security issues reported.

The security issue alluded to in this email is only one of four different scenarios around auth plugins provided to the JSST at the end of 2020... Some of the others are worse. Complete account takeover is still possible.

[brianteeman]

As a user it is now very confusing. I have two two factor authentication plugins. One called Yubikey and one called Google Authenticator.

In order to use them I have to select another option also called Authentication but this time with just the options Joomla and None.

The description says "Which authentication method you want to set on the user account" but neither of the two options (Joomla & None) appear to have any connection to the options in the other field with the same name.

However through trial and error I was able to discover that 2fa is not broken. I not only have to enable the 2fa plugins but also change the mysterious authentication option to Joomla for the user. Then save the user and hopefully spot that a new tab for two factor authentication has appeared.

As there is no default value on the mysterious authentication field it loooks like I now have to do this for every user before they can use 2fa.

Then we have the list of users which displays who is using 2fa. Except now it lies.

If you enable and set up 2fa correctly then the userlist looks like this

If you now set the mysterious authentication field to none then the 2fa tab disappears but the user list still shows

And even more crazy is that if you now try to log in without the 2fa you can not as you get

So what did the mystrious authentication field actually do apart from hiding the 2fa setup tab?

In conclusion this pr cannot have been tested at all.

1. The user interface is misleading
2. The user interface doesnt work as I'm sure you intended it to
3. Setting the authenticator to none does not disable the authenticator

The only thing that can have been tested is the security issue as certainly no one actually tested it in a real world environment or they would have spotted all of this.

[PhilETaylor]

So what did the mystrious authentication field actually do apart from hiding the 2fa setup tab?

It stops you logging in with Gmail or any other 3rd Party Authentication Plugin. It binds your user to the first auth provider (Joomla in your case) that you login with after the upgrade... thus, for some, this would lock them out from ever logging in with LDAP/GMAIL/GITHUB/ETC ever again if they logged in with Joomla user/pass first after upgrade.

Its pathetic. Its wrong. It should never have been merged or released.

[PhilETaylor]

The only thing that can have been tested is the security issue

Multiple security issues remain unaddressed. This new feature doesn't resolve them.

[brianteeman]

/me doesn't discuss security issues in public

[PhilETaylor]

unfortunately the release has been made - and is public. The JSST had 19 months to get this right.

/me led the horse to the water, but I cannot force it to drink.

[nikosdion]

Hey, guys... It gets worse. This idiotic feature locks you OUT OF YOUR SITE after upgrading. See https://github.com/joomla/joomla-cms/issues/37411 and https://github.com/joomla/joomla-cms/issues/37413

You can't make that up! This is the first time in 16 years I am NOT installing a security update on my business site because it will lock my paying clients out!

Is there a way to start a vote of no confidence against the JSST? Even though the JSST asked for external input — at least from @PhilETaylor — it promptly disregarded the negative but constructive feedback without as much as a second thought, pushing through with a disastrous implementation that breaks Joomla. How is this even remotely acceptable behaviour?! Core contributors have been banned from the project for far lesser infractions.

[brianteeman]

Confirmed

[brianteeman]

Actually it might be a different issue I am confirming but probably not. Despite having webauthn set up and yubikey with both working before the update I can no longer long in using webauthn

[PhilETaylor]

And so it begins...

[nikosdion]

@brianteeman Nope. I tried that too. The WebAuthn login takes place in the plugin where there's no check for authProvider. I have two users on my test site. One was first logged in with password (authProvider is Joomla) the other one was first logged in with WebAuthn (authProvider is PasswordLess). Both have WebAuthn set up. The first user can login with a password OR with WebAuthn. The second can only log in with WebAuthn.

[brianteeman]

so its the same issue.

oh well not much I can do

[nikosdion]

@PhilETaylor It's almost 11pm and I have to write a coherent announcement on our site because the shitstorm will begin very soon for us too. People either being locked out and wrongly blaming Admin Tools, people trying to restore backups and people who are at a loss and ask us for help. Whee! All hail the mighty morons who implemented the most IDIOTIC user “security” feature which simultaneously reduces security (disables TFA on non-Joomla logins), locks people out of their sites and does NOT address the reported security issues. What the actual fuck!

[PhilETaylor]

3rd March 2021... Phil Taylor Wrote (after decades of experience):

silently and without notification, forever potentially locking them out of their account in the future...[..] very lacking, very incomplete and not fit for use.

/insert funny meme/

[nikosdion]

[SniperSister]

Ok everyone, at first, let me try to summarize the intention behind the change.

Phil reported numerous valid issues related to the authentication process. Those issues can be categorized in two groups:

a) "Auth provider switching issues": in these scenarios, the fact that user does not bind users to specific authentication plugins lead to various attack vectors. One example: Imagine a scenario where a company is running an intranet site using LDAP for authentication. An employee logs in the intranet site using his LDAP credentials. A while later, the employee leaves the company and the admin removes the account from the LDAP server, assuming that this will also remove the user's access from the intranet site as the employee used LDAP for authentication. However that was not true: the user could simply reset his account password and login using the Joomla auth plugin, even though his LDAP account was removed.

In order to fix these types of issues, we defined that authentication providers, that don't require an existing user row, are considered "primary" authentication providers and that a user will be bound to that primary provider on the first login - closing the attack vectors described above. All other authentication providers (cookie, webauthn etc) will still work, just like any 3rd party plugin will do.

(Yes, I realized that we fucked up the binding process, see PRs)

b) "TFA workarounds": the TFA verification code is currently sitting in the Joomla authentication plugin. That means, that we have various situations, where that code actually isn't executed and therefore TFA constraints aren't checked. That applies to sites without the Joomla auth plugin being enabled or situations, where the Joomla auth plugin is executed before the plugin, that is returing a successful authentication, is executed.

To fix this, we had two choices: 1) move the TFA verification code out of the Joomla auth plugin into a place, where it's triggered in all scenarios 2) bind TFA to the Joomla auth plugin, which only became possible because the solution choosen for the other issue group

We went for choice 2), which, without a doubt, is an opinionated choice.

I'm totally aware that both fixes are far from being perfect solutions - especially UX-wise. We tried to balance the complexity of the patch with the rather limited testing resources that the team has, and the result was a patch that we considered being a "minimal" patch, fixing the attack vectors while maintaining compatibility for most of the scenarios that we could think of.

I hope that sheeds some light on why and how that change was made. I wholeheartly agree that this was far from optimal.

Regarding that comment over here:

Is there a way to start a vote of no confidence against the JSST?

Let me be honest here: JSST is the by far most painful and frustratiting experience in the Joomla project that I ever had and there's just one single reason why I'm still on board: there's nobody willing to take that responsibility. So, show me who's doing the job and I'll very happily hand over that badge.

[PhilETaylor]

19 months, you told me the packages were ready in July 2021 but needed more testing, ... and this is where we got to... despite repeated warnings that the approach was wrong... you pressed ahead with it.

The approach is still wrong, and will still be a backward incompatible forced change that can still lock people out of using multiple different logins

If the JSST cannot fix serious valid issues, correctly first time, within 19months then it should simply be disbanded and all security issues resolved in public.

I shall be reporting all security issues in public from now on.

History repeating itself again - another pulled update - more user trust in Joomla eroded ...

[brianteeman]

The problem with the UX is that even after reading your description it is not possible to offer any suggestions as I still dont have a clue what the new authentication field does. I like to think of myself as quite an advanced user so if I havent got a clue what will the regular user think.

If you could explain the following we can try and fix it

1. What does this new field do and what are the values joomla and none
2. If the value is none which removes the tfa tab then is tfa disabled for that user - if so then the list view needs updating
3. Could there be a default value for this new field? I still dont really know what it does so that might be a stupid question.

As for limited testing resources. The entire JSST, CMS Release Team and presumably the entire Production department are surely trusted as testers. And after that you have knowledge of a large number of experienced contributors who would only be too happy to test things. You just have to ask.

Trying to be constructive here

[PhilETaylor]

IIRC the new field is the ONLY auth plugin that user will be allowed to use.

So like gmail ldap or Joomla

None means it's not yet set but will be automatically set to something else on your next login by Joomla. If you login with ldap it will be set to ldap

Basically it means if it's set to Joomla then you can never login again with ldap or gmail or other auth plugins

If it's set to ldap you cannot login with Joomla username and pass

Thus is totally breaking 20 years of being able to login using multiple auth plugins

[SniperSister]

What does this new field do and what are the values joomla and none

The field defines which of the primary authentication plugins (Joomla, LDAP, Gmail) is bound to that user. If a plug-in is chosen, only that plug-in can be used as the primary provider, making Joomla skip the other primary plugins. Non-primary plugins (cookie, webauthn) will always be checked regardless of the fields value.

If the value is none which removes the tfa tab then is tfa disabled for that user - if so then the list view needs updating

Any other value than “Joomla” disables the TFA settings tab for that user.

Could there be a default value for this new field?

On sites with only one plug-in enabled you could hide that field completely. On sites with multiple plugins, a default value for new users could be “Joomla”.

Trying to be constructive here

Much appreciated :)

[brianteeman]

And what does the value none do

[PhilETaylor]

Allows you to login - once - with any auth plugin

None means it's not yet set but will be automatically set to something else on your next login by Joomla. If you login with ldap it will be set to ldap

[nikosdion]

First, let me address your claims that this feature fixed anything.

a) "Auth provider switching issues":

This issue is not solved by this feature.

There is no user or administrator opt-in for the user authentication method. Any enabled authentication plugin will kick in before the first log in. As Phil pointed out, this would mean that if let's say the Gmail authentication plugin is enabled you can take over an account as they're not bound to any authentication method.

The correct way to handle this, as demonstrated in Akeeba SocialLogin, is to have the user EXPLICITLY bind the external authentication to their Joomla user account. Moreover, it must be up to the administrator to decide if an auth method should magically create a Joomla user or not. Joomla has been violating these basic two principles since 1.0 and your feature does not address that at all.

Further to that, your example sucks. I would have fired that administrator and the entire IT Security team for failing to create a comprehensible document of steps to follow upon dismissal of a user from the company. Instead, your "solution" is to lock the user into a single authentication method. I'll get to why this is a problem.

Moreover, you are deliberately ignoring the far more common use case of deliberate use of multiple auth methods such as but not limited to allowing the user an alternative form of authentication (social media login, WebAuthn) or bridging with an external application or authentication system (e.g. an SSO, forum bridge, ...).

Additionally, you are overriding the user's express intent to use ANY available authentication method by always overriding the None option with whatever they used last time. Why give people the None option if it cannot be used?!

b) "TFA workarounds"

This feature does not solve this problem. As a matter of fact, it merely disables TFA for the use cases you don't want to be bothered to fix.

I will try to approach this in as neutral terms as I can. It's not easy because I was the developer who contributed TFA and know how it ended up being that horrible mess we have in the core — despite my clear warnings that it'd be a bad solution. History lesson. Let's go.

Back in 2010 to 2012 I was offering basic TFA in Joomla backend logins through Admin Tools. Because of the constraints in Joomla 1.5 and 1.6/1.7/2.5 the only way for me to do that was to add a TFA code field in the login form using JavaScript even though that's a bad idea because the code is phishable in this case.

When I offered to implement TFA into Joomla in 2012 I told you guys online and in person (JoomlaDay France 2011, IIRC) that the BEST way to do that would be a captive login: login the user with whatever auth method they use, show a captive login page where no modules and no components are executed, have them enter their TFA code and then proceed to a “full” login. You all told me that this is impossible and would require massive changes in Joomla so this would have to be implemented in Joomla 4.

(The JSST was not consulted back then. In retrospect, that was weird as fuck but what can you do).

Back then the upcoming version was Joomla 3.2. Your stated plan was to release 3.2 Short Term Support in late 2012, six months later 3.5 Long Term Support and six months after that Joomla 4.0. I agreed to contribute the subpar solution – even though adding a field to the login form was far more disruptive for third party login module developers — on the basis that in a year's time we could do it the right way.

Imagine my surprise to find out in March 2013 that I was no longer allowed to work on TFA plugins or, in fact, on TFA itself because Joomla would no longer accept any feature depending on third party hardware or software! Apparently a couple loudmouths stupidly complained that the Authenticator method requires Google Authenticator and Google is evil — nevermind the fact that the documentation of the feature said explicitly that it's compatible with ANY TOTP authentication software and I had linked to the very much non-Google application Authy as an example (that's what I was actually using to develop this feature!). Another fabulous Joomla self-own, but I digress.

Imagine my even bigger surprise to learn that Joomla 3 would continue with 3.3, 3.4 etc until Joomla 4 would be released “sometime in the future”.

Basically, Joomla conned me! TFA, as it is implemented today, is the one contribution I've made to Joomla that I've come to regret. Had I known I'd never be allowed to touch it again I'd have NEVER considered, even remotely, to contribute it to the core. That's why I was so reluctant with WebAuthn and it looks like I was right, I am still not really allowed to do much needed improvements to it within the lifetime of Joomla 4. Sigh...

After Joomla 4's false start in 2015 and it getting stuck in limbo I was properly pissed off by the subpar TFA in Joomla and no public indication that the policy had changed (apparently it did, not that anyone bothered to let me know, what else is new). So I did what I do best: I wrote an extension to prove that it can be done. Hence the creation of Akeeba LoginGuard, with a captive login page that does NOT need ANY change in Joomla. Even if we merged its system plugin into Joomla's application object it would still be fully b/c unlike what you were all telling me in late 2012. At this point it's well over six years this extension has existed and it's already reached version 6, 100% Joomla 4 native, no third party framework in use. You can merge it into Joomla and you're in business, baby!

If you REALLY wanted to solve the problem that the TFA is not applied consistently you could have just asked me to contribute LoginGuard to the core. I'd have gladly done so. As I said and as I have documented, I wrote it because I regret the TFA feature I contributed. It was not what I wanted to contribute, LoginGuard is.

Instead, you chose the worst possible solution: disable TFA completely unless you use Joomla's password authentication. Eek!

This means that people using LDAP, a forum bridge or any other kind of authentication plugin to validate their passwords are now completely unprotected against brute-force attacks, despite the exact opposite taking place for the past ten years.

Sorry if I may sound pretentious, but I do have two questions on that:

1. How is this NOT a breaking change that should have been introduced in a new major version after public discussion and scrutiny?

2. How is degrading the login security after ten years considered a “security” fix to begin with?

There are people out there relying on this feature. Given the nature of auth plugins and TFA they are very likely to be organisations which do not appreciate a potential violation or regulatory requirements in a minor version marked as “security release”!

I'm totally aware that both fixes are far from being perfect solutions - especially UX-wise. We tried to balance the complexity of the patch with the rather limited testing resources that the team has, and the result was a patch that we considered being a "minimal" patch, fixing the attack vectors while maintaining compatibility for most of the scenarios that we could think of.

It's not a solution as it fails to properly address either problem. The first problem is not fixed at all, the account spoofing Phil reported is still possible. The second problem is “fixed” by disabling TFA which is a blatant cop out!

Moreover, this is NOT a security feature that benefits from being developed behind closed doors. It's not like nobody knew that the Joomla auth stack is triggered as a whole. Everyone who understood login security was keenly aware of the risk introduced by Joomla's authentication stack which is why very few were using it. Not to put too fine a point on it, developing this in the open would have saved you from the embarrassment of a disastrous anti-feature which degrades security and breaks people's sites.

Let me be honest here: JSST is the by far most painful and frustratiting experience in the Joomla project that I ever had and there's just one single reason why I'm still on board: there's nobody willing to take that responsibility. So, show me who's doing the job and I'll very happily hand over that badge

Since you are quoting me, I am obliged to respond.

Yes, being in the JSST is very frustrating. Even more so when there are not enough people who understand how the product is used in the real world. Security is a hard discipline at the intersection of paranoia and usability. Finding the balance requires a skillset that no single team can possess.

I do not take offence at you personally running the JSST. I am taking offence at the approach you took for this feature. It was very clear that your team's understanding of the issue and how it affects the product's real world use was encumbered by the constraints of having a small, isolated team. The reasonable thing to do is seek outside feedback from the people who understand the subject matter (login security), even better if they also understand how the product is used and how to write usable software. You already have mine and Davide's email addresses. You did not contact us. Apparently, you only contacted Phil, he told you that you are heading the wrong way and you doubled down. Now that I came here to tell you pretty much the same things Phil did you are doubling down again. This is bad leadership.

The greatest leadership qualities is admitting one's limits of understanding and owning up to mistakes. OK, you made a mistake. It's not the end of the world. If you can at least admit that we can and are willing to help you fix it. If you keep pretending nothing is amiss we will get nowhere, we'll be frustrated at each other and we might say things that we regret.

To that end, I have to offer...

...constructive feedback

Joomla's authentication plugins are in serious need of refactoring if not reimplementation. Ideally, Joomla's password authentication should be built-in and always used as a fallback if no other auth method exists. Let's not repeat Linux' mistake of being able to disable all PAM methods and end up with a brick. The rest of the plugins need to be reimplemented as system plugins which allow the user to opt into them. Yes, there are use cases where you want to force them to be used. No problem, you can have that as an option in a system plugin called System - Forced authentication. Select which methods are allowed and required for each user group. You want to force all Managers and above to use LDAP? Check. You want to allow frontend users to use password authentication and WebAuthn but not LDAP? Check. You could even go all fancy and create composite rules, e.g. if WebAuthn is enabled do not allow a fallback to core login (password).

Unfortunately, for obvious reasons, this cannot be done before Joomla 5. I am volunteering to help with that. It should be more than obvious that I do have real world experience on this subject (LoginGuard, passwordless authentication / WebAuthn, SocialLogin).

I would also say that Joomla desperately needs a captive TFA, just like LoginGuard does. I have no problem contributing it to Joomla. Whether it would be a Joomla 4.2 feature or a Joomla 5.0 feature I don't mind. Tell me you are serious about it and I will do the PR. There would be an automatic migration from the legacy TFA to the captive TFA, nobody would notice any difference except that the Security Code field is no longer in the login module.

For now, Joomla 3.10 and 4.x, you can at least do damage limitation and set a solid foundation for the future.

• We need to query both authentication and system plugins in the Joomla\Component\Users\Administrator\Field\PrimaryauthprovidersField. We also need to implement the Joomla\CMS\Authentication\ProviderAwareAuthenticationPluginInterface in the WebAuthn plugin along with a provider check in the login method and publicise that instruction for all 3PDs making non-password plugins, like yours truly. The only problem with that is that you DO need to bump the versions to 3.11 and 4.2 because you introduced an interface which is not available in previous versions. If you can't do that, revert your solution and let's talk about how this can be done WITHOUT using an interface.

• Make the authProvider field multiselect. There are legitimate use cases where it's desirable to have multiple authentication methods. For example, you could have WebAuthn and GitHub login as a backup.

• Add an option to the User - Joomla plugin to provide a default set of allowed authenticators. Add another option to determine whether the None method is allowed. If it's allowed don't override an empty list of authentication methods. Rename the None method to “No preference”.

• Change the “Authentication method” label to “Allowed user login (authentication) methods” to differentiate it from the TFA setup.

• Restore the TFA checks regardless of the authentication plugin used, notwithstanding the implementation of a captive login. This will at the very least fix the security degradation for existing users until the better solution is implemented (if ever).

[brianteeman]

Make the authProvider field multiselect. There are legitimate use cases where it's desirable to have multiple authentication methods. For example, you could have WebAuthn and GitHub login as a backup.

This is my biggest concern.

[SniperSister]

Thanks all, I will follow-up with a longer post, but first let me make a suggestion: The feedback here and the fact, that the issues that we tried to fix are considered „public knowledge“ anyway makes me believe that the best solution for now is to remove that new bind-check code and the field from the update to allow the other fixes being shipped. Afterwards, we can sort out a proper mid and long term solution. Any objections?

[brianteeman]

100% agreed

[brianteeman]

As a first step I would create a tree diagram of how someone can authenticate and from that establish what/where the reported issue needs to change. It will be much much easier to write the code when the exact behaviour has been established. That's what the problem was/is here. All the possible scenarios were not considered at the beginning.

[nikosdion]

The feedback here and the fact, that the issues that we tried to fix are considered „public knowledge“ anyway makes me believe that the best solution for now is to remove that new bind-check code and the field from the update to allow the other fixes being shipped. Afterwards, we can sort out a proper mid and long term solution. Any objections?

I agree.

Short term solution: stop the ongoing crap storm. Then we can all work together to make this into the good feature it has the potential to be. I'm all for it.

[SniperSister]

@nikosdion any strong opinion on the question if we should leave the DB column for the yet-to-be-implemented mid-term solution and just remove the field and checking code? Or should we also remove the sql-file and add a snippet to the script.php deleting the column if it's exists?

[nikosdion]

@SniperSister I agree on leaving the column. As I said previously, this field will be useful if we make it multi-select and list all authentication methods. Leaving it there, inert for now, sounds like an excellent idea.

[SniperSister]

Ok, I have updated both PRs accordingly, could you please check if I have overlooked anything?

[brianteeman]

No harm done in leaving it there BUT it would mean that some sites have an extra field which might cause an issue wih some integrity checkers

[SniperSister]

No harm done in leaving it there BUT it would mean that some sites have an extra field which might cause an issue wih some integrity checkers

No, because we leave the SQL file / script.php block in place, so all sites, regardless if they have installed the pulled back update or not, will end up with having the field.

[brianteeman]

ok - all good then. my bad for not looking at the code before commenting

[SniperSister]

Hi all,

so, with the release-breaker being fixed, I would first of all like to thank of you for the input and help, I really, honestly appreciate it!

Before we talk about further steps being taken, I would to first like to apologize for creating the impression that I'm not interested in your feedback or tried to talk down to people. That was never my intention, I just wanted to explain our motivations and thoughts behind the initial change, as it obviously wasn't clear if one doesn't know the actual issues. I'm also directing this excuse to you, Phil. I didn't want to give you the impression that I'm ignoring your concern – that's why I followed up twice after your mail, trying to summarize the scenarios that we are trying to fix and if I understood your concerns correctly. Did you get those mails? If not, we should fix that asap to make sure that the line of communication works properly! I would also like to offer that you, @PhilETaylor and I schedule a meeting to sort out the issues of the last weeks and months to start talking with each other again instead of talking about each other. Let me know if that's an option for you!

That being said, I would like to suggest the following next steps:

1. I'll re-read Phil's reports and work on a summary describing the scenarios that we are trying to fix - I'll sent that summary to Phil, making sure I haven't missed anything
2. Afterwards I would like to arrange a meeting with a bunch of JSST folks and the three of you to discuss potential short- and long-term solutions
3. We start working on the patches and do a release
4. JSST will review the security policy and discuss, if we can i.e. patch "low-severity" but "complex-to-fix" issues in public PRs to get more feedback and/or formalize the inclusion of external advisors for specific issues

Would that work for everyone? Any objections?

[PhilETaylor]

In the meantime Joomla remains insecure, unpatched and hackable though multiple core and 3rd party authentication plugins under non-insignificant conditions - 19 months after the first report of a security issue was made to the JSST, and you don't seem to think that timeline is an issue...

I reported several issues, but thinking out of the box (like a hacker) the root problem extends and could extend further into other authentication bridges and plugins.

Along with this, You were told on 3/10/2020 that 2FA could be bypassed and It should not be the Authentication plugin responsibility to enforce 2FA and that captive login was needed (Nic has repeatedly offered to supply this)

On this day there were ELEVEN VALID SECURITY TICKETS OPEN from me with the JSST (as per Tobias confirmation email - Saturday, 3 October 2020 at 08:15:11)

On 3/10/2020 Tobias stated that your chosen solution was out of your hands and that it was your intention to bound a user to a auth plugin and thanked me for my DETAILED reply expounding the issues.

thanks for your detailed reply.

"What solution is choosen is out of the control of the JSST and is up to the maintainers / release leads to decide on.

On 3/10/2020 I stated (as part of a very long email)

You have not shared you plan on how to fix both issues by bounding to a specific authentication plugin, in a backward compatible way… I cannot think of any way that it can even be achieved in a backward compatible and secure way. There is no reliable way of knowing which local users were created by login with a plugin, or were created as a local db user. Also remembering that Gmail is only one of an unlimited number of authentication plugins available

Even if you lock a user to its authenticator, the current way 2FA is implemented means 2FA will be bypassed, even if a user has it enabled.

You said on 7th July 2021 that the patches were ready but needed additional testing so were not added into Joomla 3.9.28 - on that day I shared 502.diff with @nikosdion by email

I cannot find evidence of my feedback on that day.

You were told later in July 2021 that your approach with locking a user to an authentication plugin was wrong.

You stated in December 2021 that the Joomla 4 patch was on your Christmas holiday todo list.

You were were specifically told again on 3rd March 2021, following you proving your patch files for review, that your approach was wrong and that the patch reviewed was not fit for purpose. You were specifically told that it would lock users out of their accounts.

But yet you chose to ignore the specific feedback provided and release anyway.

I don't see how any more meetings, any more words, are going to convey how disappointed I am and how avoidable this whole situation was. I have repeatedly spelled out the problems, and repeatedly given timely feedback only to be ignored.

I have repeatedly spelled out time and time again what the security issues are. read my emails from 23rd September 2020 which are literally pages long, why do you need to summarise the issues yet again.

You are meant to be a Security Team, you are meant to be able to take an initial report, and think out of the box on its knock on consequences and not only fix what was spelled out but to read between the lines and also fix things reporters might not have thought about when reporting their findings.

I have repeatedly chased the JSST since logging this - and many many other issues

There is nothing more I can add. Nothing a meeting would resolve. Nothing more I can say. I have tried and tried. Repeatedly. 7.18% of all the public issues ever opened in joomla/joomla-cms have been authored by me ( and 4% of all PRs in the repo) - and a high number of security ones in private too, 20 years of investment. I have served on the JSST multiple times. Hell I even wrote the google doc documentation for the JSST that is not followed and set up the first ever GPG Encryption keys for the JSST! Im consistently in the top 5 contributors graphs

The problems in the JSST are institutional and systemic of the whole of the project. Leadership failures

Its clear that this project doesn't value contributions from certain people. So, recently, I have closed all my open issues on GitHub (100+ valid issues) and all my pending PRs (A move that was not announced by me, and not acknowledged in any part by the Joomla project, losing 100s of pending contributions and open issues on a single day!) in this repo and I'll bid you farewell. I only returned to ensure that you were aware of the monumental screw up that was made in the release.

https://developer.joomla.org/security.html states:

Within 21 days every report must be resolved unless there are exceptional circumstances requiring additional time

LMAO. 19 months.

[nikosdion]

@SniperSister I am perfectly fine with your proposed course of action. Please do give me a lead time of at least a week before scheduling any meeting as I have to coordinate with my wife who has a ton of meetings to make sure there's always an adult available to take care of our daughter.

I'll be more than happy to contribute my experience on login security and two factor authentication. I also have a few ideas about how the JSST could handle low severity but tricky issues.

I'll also go ahead and close this issue as it's been addressed with today's releases. The underlying issues have not but, as you said, we'll get together and get things done “all together as a whole” (to quote Joomla's historic tagline).

[richard67]

lts clear that this project doesn't value contributions from certain people.

@PhilETaylor WTF … lots of your contributions were valued and merged. So what made you think that? Just because we did not test them fast enogh? You know we all are volunteers who have a life beside Joomla, and often a paid full-time job beside it. It sometimes needs time until PRs find testers. @nikosdion can tell, some of his PRs took longer because they required knowledge and skills for testing, but at the end they were merged and much appreciated, and it would have been the same with yours.

What makes you always think that your PRs take so long because we all hate you as a person? First of all that’s not true, at least I can say from me and all people I know that we hate nobody here, and secondly it seems really paranoid to me.

Take @nikosdion as an example how adult people act, maybe you can learn from it.

[SniperSister]

I am perfectly fine with your proposed course of action. Please do give me a lead time of at least a week before scheduling any meeting as I have to coordinate with my wife who has a ton of meetings to make sure there's always an adult available to take care of our daughter.

Perfect, will follow up with the summary and a suggestion of meeting slots on monday!

[lancedouglas1]

As a product manager and having been involved in several IdAM projects, I'd like to offer time to support the security in Joomla. I've been actively using joomla since J1.5 and security has been my only real concern.

How can I join the JSST board or at least support it?

[SniperSister]

@lancedouglas1 happy to hear that! Please send an email to security@joomla.org, thx!