I have said since 2011 that 2FA can only get us this far since it requires providing the verification code together with the authentication information. This has the problem that it prevents us implementing any verification step which requires interaction such as but not limited to U2F (kinda dead), WebAuthn (we added it as a primary authentication), sending a code by text / email / push message, support for third party services like Duo etc.

The correct approach as I had been saying since 2011 would be Two Step Verification. Login into a captive login where modules and components don't run except for the bare minimum to process the verification. That's how literally everyone else is doing it.

You might think it's a bit hypocritical of me to say this having contributed 2FA to the core. Contributing this to the core was supposed to be a stop-gap to improve Joomla login security without any backwards compatibility impact. Basically, the production team didn't believe me when I said that I can implement a captive login without breaking b/c and they'd only agree for me to contribute TFA with its known limitations.

However, the Joomla release schedule at the time was a final 3.3 release and a Joomla 4.0 six months later. The understanding was that I'd be contributing a real, Two Step Verification solution in Joomla 4. That was just one year away at the time so, sure, made sense and I did agree to do that for Joomla! 3.2. Instead, the scope of Joomla 3 was expanded by another six years(!!!) and I gave up. Seeing the J4 effort stagnating circa 2016, I just released my code as Akeeba LoginGuard, putting my code where my mouth is and proving that it can be done without breaking b/c. It's funny that the Joomla! project eventually even copied parts of my captive login code for com_privacy's system plugin but still didn't bother implementing two step verification.

Regarding your issue, I disagree it's a security issue per se. If you disallow logins without TFA when you are enforcing TFA how exactly would a user enable TFA in the first place? It's not like the administrator can (or should!) enable it for them. The whole point is for the user to have something they own on top of something they know. If you start emailing QR codes around you might just as well disable TFA. If we were talking about 2SV with codes sent by email / text / push message I'd agree with you but ONLY if there was a fallback method that'd always work (e.g. OTP by email) as a bare minimum. This way a legacy user would have been sent an OTP by email which while not exceptionally secure does raise the bar for account takeover -- BTW, this is on my to-do for my own software, I didn't come up with it on the spot.

I do, however, agree that showing the full site chrome including modules is a mockery of enforcing TFA because the user can still interact with the site, albeit minimally. Whether that's a security issue strongly depends on the content of the modules and whether they can interact with plugins without going through com_content (the legacy way of doing AJAX).

The correct solution to this issue is having a captive login page in com_user for editing the user profile when TFA is forced or when com_privacy asks for it, without showing modules. It's feasible and I've already written the code which does that. If you ever go through that trouble you might just as well implement real Two Step Verification so that methods other than OTPs generated on a user's device before they login can be used for verification. Basically, you'd have to reimplement Akeeba LoginGuard in com_users which was the original plan we had come up eight years ago today, give or take ten days.

We dont disagree on this and I know it has a history, and you are right the correct solution is to login to a non-chromed page that ONLY allows you to set up 2FA or logout (If Enforce 2FA is enabled and you have not yet set it up).

At the moment, after login with username/password, even with 2FA Enforced (but not set up) a user/hacker can:

• View the users Joomla API Token
• Reset the users Joomla API Token - gulp
• Reset the users password
• Change the users name
• Change editor, Time Zone, Frontend Language, Backup Template Style, Backend Language
• Turn off email notifications
• Change events to email settings
• change the admins email address!!!
• Set up 2FA (Cant - because its broken at the moment see #29300)
• See any modules/content/data published for their access level (could be a super admin) that might be surrounding the users "Edit profile" page.

What they should be able to do is

• Logout
• Set up 2FA
• Nothing else. Zip. Nil. Nada

Right, I had forgotten about all the other user profile fields. See, I have never used the user profile for anything other than its intended purpose: edit the user profile when the user explicitly requests it. For LoginGuard I implemented the captive login as a separate component so I could sidestep the noisy and risky environment of the user profile page. The core could easily do that without a new component, just a new view that cannot be assigned to a menu item. For anyone who understands how Joomla works it's an almost trivial task.

As I said, if this is implemented we can finally have real Two Step Verification and we can get rid of the clumsy Secret Code field in the login page. IMHO that would make the interface cleaner and more intuitive. Fun fact: I implemented LoginGuard because my clients were confused with the Secret Code field and were asking me what they should put there and why do I keep a secret that prevents them from logging in ?

Optional removal fixed in #29339. OK to close?

It is optional and should be optional and therefore #29339 could be improved slightly to actually show optional on this field again.

because even with "Enforce" set to on, you can still login without a secret key by design if, and only if, you dont yet have 2FA enabled on your account. So it can never be "Required" ever... therefore is always optional.

That leaves the bigger conversation about how 2FA even works (The fact that with enforce enabled, I can still login (with user/pass) without 2FA, and Im able to make huge changes to my user profile without still enabling 2FA), and Im afraid if you close this issue for the "optional" part - then it will get kicked into the long grass again when its actually quite important.

I have emailed the Joomla Security Strike Team regarding it, but I have yet to receive a response.

Which you should know better than to state publicly

I don't think it is prudent to openly talk about security issues in public before a patch is available.

As for the matter at hand, I appreciate what you are saying but your suggestion does not solve the problem you are describing (an attacker gaining access to a Super User's username and password BEFORE said Super User got to enable the enforced 2FA). Let's say we implemented the captive 2FA enforcement page where the user can only set up 2FA or log out. If you think really hard and long about it you'll see that the attacker can still log in, enable TFA (locking the legit SU out of the site), log out and then log back in where he can do everything you said is a problem. So... from an implementation point of view you have expended a lot of effort for sod all security improvement.

Again, the only way to actually ENFORCE 2FA is that option denying login to all user accounts which do not have 2FA enabled. However, Joomla being a mass distributed CMS, it would mathematically lead to users locking themselves out of the typical Joomla site that only has a single SU account without any obvious way to get back in. This kind of secure enforcement that addresses the attack mode you described requires an IT department. Yeah, it'd be ideal, but it's not what we can reasonably expect from Joomla's users.

We could discuss in length about alternatives, like receiving codes by email in this case, but this opens a whole new can of worms. Can you trust email? What if the attacker has already compromised the person's email which is typically step number zero in the kind of targeted attack you are describing. If we add an override in configuration.php (like we have for when you screw up and end up with no Super User account) are we not adding a backdoor for an attacker that discovers a vulnerability that allows them to "only" change files / Global Configuration settings? How long is a piece of string? You see where this is going.

The current TFA implementation in Joomla is dated and doesn't make sense in the context of the modern web. Web Authentication does solve those problems but, still, we do have fallback username/password logins. Ideally username/password logins would be an optional plugin and the site owner could choose to only enable Web Authentication (or any other third party login mechanism). Even better, the plain old credentials authentication plugin would have an option to disable logging in with a username and password if another login mechanism is available. THIS would solve so many more issues than a half baked enforcement of TFA.

Just my two cents.

No, you are misquoting me out of context.

What I have said SINCE 2011 is that Two Factor Authentication where you enter a code WITH your username and password is not the right way to do it. The right way to do it is with a Second STEP Verification where you use whatever to complete the initial login (typically a username and password but could also be SSO, Facebook login, etc) and THEN being asked to complete a second verification step. The second verification step can be a code generated by a device, a code sent to you by SMS/email/push message/smoke signals/telepathy, U2F/WebAuthn or anything else.

So, what I am saying is that the TFA implementation is not good enough because:

a. it confines the second factor to a generated code which is limiting both for UX and for security; and

b. it happens during the credentials login which makes it phishable

I did not say anything about it in the context of enforcing the use of 2FA by accounts.

What Joomla does is better called "force" (I agree that "enforce" is definitely the wrong word). In simpler terms, it forces users to enable 2FA.

To make it abundantly clear, even though I am merely repeating myself after four months, is that I do NOT think that Joomla's current 2FA is any good. IT WAS ONLY EVER MEANT AS A TEMPORARY SOLUTION FOR 6-12 MONTHS. It was not meant as something that would be with us for over a decade, for crying out loud! When I made my contribution of the 2FA code I made this abundantly clear, as well as that the correct way to handle that is via a Two Step Verification system which involves a captive login page for the second authentication factor, just like everyone else is doing.

I'm sorry that the leadership changed and they kicked me in the curb. I'm sorry that the rest of the people with decision making power since don't give a rat's bottom about security. That's really not something I can do anything about. All I can do and have done is implement my original vision of how Two Step Verification should work and make it available free of charge.

the only way to actually ENFORCE 2FA is that option denying login to all user accounts which do not have 2FA enabled
Which is EXACTLY what the feature says it does. But fails to do.

No, it doesn't. It's supposed to be a "force 2FA" feature but the language is crap, the documentation is non-existent and the code is... let's say "minimal effort" and leave it at that.

Again, IN THE CONTEXT OF JOOMLA, THE MASS-DISTRIBUTED CMS USED BY NON-EXPERTS the "Enforce" option does not make sense. It would only end up locking people out of their sites.

It is possible to write a small user plugin which checks whether the user does not yet have 2FA enabled and automatically fail the login process. THIS would be enforcement. Write it and make it available to the general public. Within 6 months you will see why it is a stupid idea in the context of mass distribution to non-expert users.

Stop thinking in the context of your service, Phil. Whatever you implement, you are doing end user support and can rescue them when (not even "if") they cock up. Likewise, on my own site, I do give the users the option to enable 2SV and I do get at least one email every second day with someone who managed to lock themselves out because they changed phones and forgot to keep a copy of the backup codes. And these are the high end users who know better. We can, should, MUST expect much worse from the general public who doesn't really understand what this blasted TFA thing is but it sounds like a good idea so click here to enforce it, oh crap, I am locked out of my site. If you can't understand the audience the product is marketed at then, clearly, you are the wrong person to make a suggestion, let alone a decision, about implementing a feature which WILL lock people out of their sites, something they will blame on the product, not themselves.

I'm out, too. I thought you had a bit more brains than what you are demonstrating here, today.

First, I do not appreciate people taking what I have said out of context and distorting it to fit the story they are trying to sell. I have been consistent in what I've said since 2011. My words, in context, are even on this thread – see May 31st, 2020.

Second, I told you that I agree with you that the word being used is wrong. It should be "force", not "enforce".

Third, I disagree with you on what this feature (regardless of whether it's called "force" or "enforce") should do. What Joomla currently implements with the "enforce TFA" is the correct approach for a mass distributed CMS. It has the wrong label and I'm not exactly thrilled about the code implementing it. But I do agree with the overall idea.

You say that you do not think that the current implementation is a good idea. So what would be a good idea? A feature that will effectively lock you out of your site, making you blame Joomla for it (because as the typical Joomla user you do not fully grasp what Enforce TFA means and don't know how to rescue yourself from what is ultimately a self-inflicted problem)? I don't think you believe that but you also can't say so because you'd be admitting you're wrong. So, yeah, let's leave it at that.

A feature that will effectively lock you out of your site, making you blame Joomla for it (because as the typical Joomla user you do not fully grasp what Enforce TFA means and don't know how to rescue yourself from what is ultimately a self-inflicted problem)?

Yes I am saying EXACTLY THAT. Im not admitting Im wrong by saying that.

Im saying you cannot call a feature "Enforce 2fa" and then DONT enforce the use of 2fa. Call it something else, remove it, but don't imply it does one thing by its name, when it clearly doesn't.

Again, IN THE CONTEXT OF JOOMLA, THE MASS-DISTRIBUTED CMS USED BY NON-EXPERTS the "Enforce" option does not make sense. It would only end up locking people out of their sites.

Finally we agree on something, however the project have implemented it so it should at least do what it says it does. And there we disagree again. I say it should do exactly what its name alludes to, and lock people out, but you disagree and say that even with enforce 2fa enabled, users should still be able to login...and set up 2fa (and unfortunately also do the long list of things below).

I am saying, and the word "Enforce" give credence to, that if you enabled "Enforce 2FA for your site/administrator" then EVERYONE SHOULD BE LOCKED OUT unless they authentication with 2FA. It should "Enforce" that policy.

I don't know of another system where you can Enforce 2FA and then still allow users to login to that system without 2fa, to set up 2fa...

even with "Enforce" set to on, you can still login without a secret key by design if, and only if, you dont yet have 2FA enabled on your account. So it can never be "Required" ever... therefore is always optional.

Once logged in (without 2fa, to a site with enforce 2fa enabled) you have access to see Modules and Content (that might be privileged information!!!) around my user profile (depending on the template, site layout, module positions). For example - I just logged in as a super admin (without setting up my 2fa) and now I can see all the names of recent users, or logged in usernames, or statistics that I should not be able to see because although I logged in with a username and a password - I did not provide 2FA secret key, because my 2FA is not set up.....

So currently - when ENFORCED is set up correctly I can STILL LOGIN and view PRIVILEGED INFORMATION even though I did not authenticate with 2FA

!!!! THIS IS MY POINT !!! It is a security issue !!! But it seems you disagree with that...

Once logged in (without 2fa on a site that "enforces" 2fa) you can still:

View Modules and Content that only an authenticated user can see

View the users Joomla API Token
Reset the users Joomla API Token - gulp
Reset the users password
Change the users name
Change editor, Time Zone, Frontend Language, Backup Template Style, Backend Language
Turn off email notifications
Change events to email settings
change the admins email address!!!
Set up 2FA (Cant - because its broken at the moment see #29300)
See any modules/content/data published for their access level (could be a super admin) that might be surrounding the users "Edit profile" page.

Even if you Enabled Enforce 2FA its not actually enforced... because the 2fa Plugins are DISABLED BY DEFAULT... so even with Enforce set to Both, nothing is actually enforced at all... unless you manually enable another plugin as well... and there is no warning of this at all.

So... yeah...

Anyway there is no point discussing this further. You have aggressively made your point and there are also discussions behind closed doors that Im not party to. :/

Time to step away again... nothing it seems is going to change.