?

The plugins we ship in core rely on third party services (or hardware) users may or may not use. Short of rolling our own solution that has no dependencies, this isn't a viable option.

The plugin can be enabled, thus showing the options, Im not saying that EVERY user needs to enable 2FA on their account.

Im saying the 2FA Joomla PLUGIN should be enabled by default, so the Two Factor Authentication tab is shown BY DEFAULT when editing a user and the secret key field is shown BY DEFAULT on the login page.

Which one? Again, both rely on third party requirements. Enabled or not they're still unusable. It's in part why we don't turn on Recaptcha or Gmail based login by default either.

At the moment they are buried. Deep. It just seems very wrong.

I dont see recaptcha/gmail login in the same league.

Yes, we can do better. No, I don't think turning on the plugins by default is it.

Flip things around here. We turn them on by default, brand new user hits login page for the first time. They see a field for a secret key. They don't know what that is, does that mean they can't get into the site without it?

Stuffing info in our "install complete" page isn't viable either. Too many installs still happen with tools like Softaculous where our installer is never seen.

So yes, there's a UX/onboarding issue here to fix somewhere.

Closed

closed as stated above.

Set to "closed" on behalf of @franz-wohlkoenig by The JTracker Application at issues.joomla.org/joomla-cms/20373

I don’t agree this being closed - as Micheal states there is a Ux issue to resolve

The Ux issue I think is the pathetic way the secret key field is shown always next to the username/password - no other application does that!!!

All other applications just show user/pass and after that form is submitted, then checks if 2fa is enabled on that account and if so redirects to show the 2fa input box

This also allows password managers like 1Password, which cooy the 2fa code to the clipboard on submission of the login box.

This is how joomla should work. This is how 99% of all 2FA implementations work.

This would allow us to promote/encourage use of 2fa by having the plugin enabled by default without the confusion Micheal states users would have, meaning that the tab in the edit user page would always be visible, as a prompt that Joomla accounts can and should be secured with 2FA.

Set to "open" on behalf of @franz-wohlkoenig by The JTracker Application at issues.joomla.org/joomla-cms/20373

reopened as stated above.

If Joomla supported TFA by which the user had to click a link that was sent to them via email, then I'd agree with @PhilETaylor

@mbabker will email verification ever be supported in core?

will email verification ever be supported in core?

I dont see any reason why it could not and should not be. I guess its the age old problem of finding someone to code it :) I doubt @nikosdion is going to donate that code too :)

TL;DR

My original vision was Two Step Verification (2SV), not Two Factor Authentication (TFA). The requirements for my contribution in 2012 was to implement something with a minimum of code changes so TFA it was. TFA requires providing the second factor with the login which is why we have the ugly Secret Code field. I have already proven that 2SV in Joomla! is possible, practical and easy to implement with Akeeba LoginGuard. Am I interested in contributing that code to Joomla? Nope. Joomla! made it very clear that for their own daft reasons they don't want a real 2SV solution in the core, they want a crippled system. I don't like to half-ass my solutions and I do regret having done exactly that in 2012. So I'd rather publish my own free of charge component instead of wasting 5x as much time trying to convince a handful of people to let me contribute my solution back to the core. I am at that point in my life where I'd much rather spend my time playing with my daughter than wasting it debating random people on the Internet. If someone gave me a spec sheet, a mandate and paid my time for debating other people I'd have no problem contributing. But I think we all know this isn't happening.

Longer explanation

So, my original intention in 2012 when I decided to contribute the code was to have multiple two factor authentication methods. TOTP and YubiKey were supposed to be the first ones. I completed U2F two years later (which is vendor agnostic) but it was rejected because "Joomla! does not include any code which supports or endorses third party products". This is very daft, since that precludes any kind of sensible two step authentication such as using U2F, SMS, push notifications (e.g. PushBullet), biometrics (Windows Hello / Web Authentication) etc. That's the first reason why I gave up trying to contribute anything more to that effect to Joomla.

The second reason is that the way two factor authentication is implemented in Joomla! you can not have two step verification, i.e. login first, then provide your second authentication factor. This is absolutely necessary when you want to do second step authentication by email, SMS etc. Otherwise you'd need to implement an awkward procedure like try to log in without the second factor, get an email / SMS / whatever and then try to log in again. This is just silly and would make Joomla! look broken (yes, I am glossing over the security implications because this is an impractical solution anyway).

I wanted to prove that my 2012 vision is perfectly reasonable, implementable and actually quite easy to implement. That's why I created Akeeba LoginGuard. In it I am allowed to do everything that the Joomla! Project forbade me to contribute. It is a true Two Step Verification solution, it implements second factor by TOTP, YubiKey, U2F, SMS, E-mail and PushBullet, it's extendable, it's secure. I can't waste my time trying to contribute it back to Joomla! since the project made it really clear to me that it's not interested for its own daft reasons. Also, after satisfying myself with Version 1 using only core Joomla!, version 2 uses FOF and FEF to provide a consistent experience between Joomla! 3 and 4, as well as encrypt the data at rest because GDPR happened. So I guess that makes it impossible to contribute it back without major changes.

Plus what I said above about my time. So, yeah, no, it's just not happening. Sorry. You can always use my forever free of charge Akeeba LoginGuard. I released it under GPLv3 for free out of the goodness of my heart, for real. I love the Joomla! community, I hate the politics. Releasing my own stuff for free is a great way to give back without having to waste my time with politics. Bliss.

@PhilETaylor in the absence of you contributing code to answer @mbabker stated explanation why it cannot be enabled by default and @nikosdion explanation that this is two factor not two step what is the point in keeping this open

One should not have to contribute code in order to have a feature changed for the benefit of the project. Its called contributing... you should know...

Its 2018. Two Factor Authentication should be the norm in all applications

If we can waste time with webservices, and with GDPR then we can surely implement the BASIC security of 2FA by default.

I should not have to write the code to justify that this is a valid point.

Well it'd be helpful if you would write the code if you can. These days the bulk of "regular" code contributors are pretty busy on everything else to be told they need to drop that to work on other people's items.

If you are able to contribute the code, and you certainly are, then if you really want it then you should contribute it. In the absence of that it's no one's right to demand others contribute code to satisfy you.

And this is why nothing ever gets resolved, done. And why @brianteeman gets away with abusing contributors so long is far beyond me.

Well it'd be helpful if you would write the code if you can.

I can. But as every contribution of (non security related) code for approx the last 3 years has been rejected I see no point

Its 2018. Two Factor Authentication - by default - should be the norm in all applications

Come up with a way to do it that does not lead to user confusion (UX fail) and submit a pull request. I will bend over backwards to personally see your PR is reviewed at the expense of one of the other 97 things I probably should be doing at the time. Ball's in your court because I for one don't have the time to be doing pretty much anything else right now.

@PhilETaylor Being the person who has written BOTH the code currently in Joomla! AND the code you'd ideally want to include in Joomla!, what you are doing here is called whining not contributing.

That said, I do agree that security by default is how things should be done. What I don't agree with is writing a lot of complicated code and having every Joe Ignorant and Jane Random come and bikeshed on me, making me curse the moment I stupidly decided to contribute.

So, I have the code which solves BOTH your technical issue (developed by yours truly, with known contributions in the technical side of Joomla) AND your UX issue (developed by a former Joomla! UX department lead). Yes, you can have 2SV by email -even though it's not secure- and yes, it pesters users to enable it on every login until they either do or they choose not to. So, yeah, I think we've got this covered. You can also see how it looks like by installing LoginGuard free of charge. No surprises.

All I ask to contribute my code is that the Production dept leadership gives me a clear mandate and specifications of what needs to be implemented. The only reason is that I can wave it to the face of people bikeshedding instead of providing actionable feedback during testing. It would save my time and sanity and we could actually get stuff done.

So, can y'all stop bickering for a moment? Just tell me who do I have to bribe to contribute code to this project (after June 1st when I'll be done with the GDPR stuff). My bribes are to be paid exclusively in hugs and thank you's, mind you ;)

@wilsonge you're the 4.0 decision guy here. The rest of us are "just" coders and opinionated fools ?

https://arstechnica.com/information-technology/2017/05/thieves-drain-2fa-protected-bank-accounts-by-abusing-ss7-routing-protocol/

Well, having written such an integration I would say that it's unlikely for users to implement it on their site, even if it exists, because it's expensive. It's far more cost-effective using PushBullet to deliver the TOTP codes or, if you don't care much about security, email. Regarding email, it's far more insecure than SMS authentication since it's plaintext and can be hijacked easily using run of the mill malware against your target. The best methods, security-wise, are hardware tokens, software tokens and push messages in this order.

As I said, the code is there. I've written it. I've been using it on my own business site with thousands of users for over a year. So, yeah, I'm pretty sure that people will use 2SV if you shove it on their face when they log in because "it's something to do with security" and "it's free".