Support

Logging into the site requires successfully completing Two Step Verification, i.e. 2SV must be already set up.

Setting up 2SV requires being logged into the site.

You see where the problem lies?

No, we can't whitelist the interaction with LoginGuard because that creates a loophole through which an attacker who has subverted only the username and password can add / replace the existing 2SV methods thereby circumventing 2SV which would make LoginGuard worse than useless, it would make it DANGEROUS (giving a false sense of security).

No, we can't limit the interaction when a 2SV has not been added yet because during the set up verification step you have set up a 2SV method on the site and we will disable it if you can't prove that it's also set up correctly on your end. This means that the action of adding a 2SV method would trigger the protection.

No, we can't selectively whitelist the interaction with a specific 2SV method because it's not only complicated, it's pointless when we have second step methods which allow multiple instances e.g. YubiKey and U2F. Selectively allowing interaction would allow the attacker to e.g. add their own YubiKey should the user being attacked was already using YubiKey with LoginGuard.

At this moment I see the page that asks me to define the TFA; then, I close it and proceed to work in Backend.

And I explained why in my previous post, in detail.

I activate LoginGuard, but he does not activate his TFA.

And I explained why in my previous post, in GREAT detail.

If you can not make TFA mandatory, it might be enough to see in Backend a list of users with the TFA option enabled (not their codes).

You cannot add columns to Joomla's Users page. You can only add tabs when editing a user. That's a Joomla restriction. If you find me a way to circumvent it without the need to modify Joomla's core files then of course I can implement this :)

I only point out, without controversy, that the security of the login is left to the personal responsibility of the users.

This is correct. That's the whole point of two step verification.

LoginGuard provides additional TFA tools, but nothing more.

Yeah, well, I guess we only give you the most advanced second factor authentication framework for Joomla and nothing more as in no, we don't push it down anyone's throat because that would currently defeat the purpose of improving security through LoginGuard. We write software which actually improves the security of your site, not something to provide a laborious charade and a false sense of security - we're not modeling our software off airport "security". If we find a way to force users to enable 2SV without without compromising their security, sure, we will.

f it is not possible to have a list of who is using TFA in the users administration panel or somewhere else, it will mean that we will open the profile of the individual user, one at a time.

Correct. The pages which list records are plain HTML/PHP templates, driven by data fetched by a non-overridable PHP class. Without template overrides you can't modify the former. Without hacking core you can't inject more data in the latter. This is what prevents us from doing it: hacking core defeats the purpose of security.

On the contrary, the pages where you edit a user's profile are XML forms and you can inject additional fieldsets i.e. tabs on the page. We use that to inject the TFA view using an HMVC implementation which nobody has attempted before in Joomla. It wasn't a simple task but we made it look like it thanks to over a decade of experience doing difficult things. Impossible takes a while, difficult we do right away.

The only alternative I see is providing a list of users and their 2SV status in LoginGuard itself. I am not sure how I feel about this. It is something that in all seriousness requires thinking about hard. How does that impact the user experience of administrators? Does that leave us with any possible security issues e.g. a Super User being able to access this page during the captive login? Does it diffuse the security setup of your site, requiring double configuration for limiting access to personal information (which may have GDPR implications)?

For added giggles I did try to implement the mandatory 2SV. There are two ways to implement it, bad and worse.

The bad way to implement it is to check during login if the user does not have 2SV already set up and make them unable to access any other area of the site except LoginGuard. This is the same concept as the captive login. When they add a new 2SV method the flag "needs 2SV setup" goes away and they can visit the site freely. So freely, in fact, that they can now delete the newly added 2SV method without triggering the mandatory 2SV enable. If you have not already seen why this is hilariously insecure you are caught asleep on the wheel.

And now we come to the worse way to implement it. If you want to make sure that users cannot circumvent the requirement you have to check whether they have 2SV set up on every. single. page. load. of. the. site. That adds up to 50msec which doesn't sound like much... until you realise that Joomla itself only takes 300msec to load a page.

So, I think that puts the final nail in this feature request's coffin.

BTW, implementing what I described is trivial and you don't even have to modify LoginGuard's code. You can just write a system plugin yourself, aping the way our built-in plugin handles captive login. If you really want to shoot your feet you can absolutely do it. I won't provide you with any footguns.

I was just explaining why we haven't included such an "obvious" feature. It's not that I don't understand why you need some users to have 2SV enabled forcibly. It's that it either compromises their security or leads to loopholes which circumvent your requirement. If there's no way to ship a feature that WORKS I'd rather not ship it at all.

For what it's worth, you could probably use a simple SQL reporting tool (or even phpMyAdmin itself) to generate a report of which users don't have 2SV enabled but should. After all, LoginGuard's tables are keyed to the Joomla user ID.