Close #23101?

Yes. Didn't even realise that was still open

I have no objection to that. When I first wrote the TOTP implementation back in 2011 (before it made it into Joomla nearly two years later) the only practical TOTP application was Google Authenticator and its specified that if you're not Google you have to use the username@hostname format.

In the years since Google Authenticator is far from being my go-to solution because of its deficiencies (no backup of the OTP codes, clunky interface, no support for wearables such as watches, treating non-Google properties as third rate citizens, no custom labels, no protection of the OTPs). I use either Authy or 1Password. Neither of these makes use that field from the QR (you can enter your own label) so I never cared to change that.

So, if I were to ever make a change in that plugin I'd rename it from Google Authenticator to TOTP and change the help text to say that it can be used with any time-based OTP generator such as Google Authenticator or Authy, or some password managers such as 1Password. Give people hints about their options. The only reason I couldn't do that before is that soon after my original PR for this feature was accepted there was that silly rule that we can't use third party product names in Joomla, as if our technology product exists in a vacuum. But I digress.

I am OK with this change. I would also change the name of the plugin or at least its description text to indicate this is not meant to be used just with Google Authenticator.

The help text was changed a few years ago to

Download and install Google Authenticator, or a compatible application such as FreeOTP, on your smartphone or desktop. Use one of the following:

You helped me write it ;)

Brian, we both know that linking to a Wikipedia page with mostly dead or outdated links about two pages below the fold was the ultimate cop-out. We did it because we couldn’t name any other products or services which, as I said, was the whole problem.
In any case, I don’t object to your proposed changes to the plugin. I object at the plugin’s continued existence at its current form and the rule forbidding us from explaining in plain English that it’s far more than just Google Authenticator.
I have said the following quite a few times in private and alluded to that in my security presentations since circa 2017. Please let me state it clearly for the record.
I had NEVER intended for these plugins to be a permanent solution. They were meant to be a temporary solution. The plan was always to implement Two Step Verification with support for secure hardware (at the time it was U2F, now it is its successor WebAuthn).
At the time (around 2012, if memory serves) Two Step Verification was considered by the production team to be a concept potentially breaking backwards compatibility. Fair enough, it was an untested concept for which I had not yet written any code. At the same time Joomla was committed to 6-month releases AND the next releases would be 3.2 (to include my contributed code), maybe 3.3, definitely followed by 3.5 (LTS I.e. one extra year of support after 4.0 was released) and then 4.0. Therefore we decided for me to go with a not-that-great temporary solution to be used for 2-3 years at a maximum. U2F support would ship in the next version after 3.2 and Two Step Verification would be written for and ship with 4.0. It was a plan for ramping up towards true multifactor authentication in the core and I was excited about its prospects.
As luck would have it, about 2-3 months after the release of Joomla 3.2 there were two major policy changes in Joomla. First, 3.x versions would continue until we could figure out what to put in 4.0, meaning that 2SV would end up in the far, far future. Moreover, I was told I was forbidden from using any third party products or services if they were not FOSS, including any secure hardware. That came when I tried to contribute the U2F implementation I had just finished writing. They might just as well have told me “we don’t want real multifactor authentication in Joomla”. My excitement turned to bitter disappointment but at no surprise whatsoever; Joomla never had a vision or a roadmap after all.
As far as I am concerned these plugins should not be used anymore and I don’t care about any changes made to them. The only viable solution for securing your login is Two Step Verification, i.e. authentication and verification being two separate actions, the latter following immediately after the former. Ideally, that should be done with secure hardware (built into the device or separate) using WebAuthn.

@brianteeman As PR #27367 has been merged meanwhile, you can remove the "NOTE: ..." at the bottom of the description.

Thanks for the reminder @richard67 - note removed

@brianteeman Was just testing this PR but after having applied it, switched on the plugin and went to the user edit and switched on 2fa for a user, I saw the account information still uses the old style name:

Could this be changed, too, so we see the name which is really used in field "Account"?

And when scanning the barcode in Google Authenticator app on my iPhone, I got an error message telling that the barcode "otpauth://totp/Joomla 4.0-dev/rfadmin?secret=XXX&issuer=Joomla 4.0-dev" is not a valid barcode. "Joomla 4.0-dev" is my site name. Can it be a problem that it contains a space?

Without the PR 2fa works on the same testing site.

Update: Maybe it just needs to url encode $url?

1. no that is correct as far as I understand the code/spec
2. yes it needs to be encoded

I have corrected the display of the account name
I cannot replicate your issue with the barcode

Ok, will test again later.

@brianteeman I still have the issue with barcode when site name contains a space, which is valid for site names. As soon as I change the site name, replacing space by dash, the barcode scanning works. So I think you should add code to encode the $url variable.

Update: Maybe that was not necessary before this change, because user name and domain don't contain any spaces. But the site name might.

as you can see in the first entry of the first screen shot I had no problem with spaces

You used barcode scanner, too?

All I can say is that without this PR, barcode scanning works for me, and with this PR not. Adding urlencode did not help. Maybe the reason could be that my testing site is in my local LAN, not reachable from outside?

Tested on a shared hosting environment which is reachable in internet: No change.

What app?

Google Authenticator Version 3.0.2102 on iPhone 6s with iOS 13.3.

As I cannot replicate this bug on my android I'm afraid you will have to
test and come up with a solution.

On Tue, 31 Dec 2019 at 14:28, Richard Fath notifications@github.com wrote:

Google Authenticator Version 3.0.2102 on iPhone 6s with iOS 13.3.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/joomla/joomla-cms/pull/27368?email_source=notifications&email_token=AAJ4P4N67RNUB7EEJQY4BMLQ3NJJXA5CNFSM4KAVIU22YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEH4I25A#issuecomment-569937268,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAJ4P4IVLJGJW4BBI6NZ2GLQ3NJJXANCNFSM4KAVIU2Q
.

--
Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.
https://brian.teeman.net/ http://brian.teeman.net/

I'll continue later with check what happens when I enter account and key manually. I'll let you know when I have more information. Meanwhile let's see what other testers will say.

@brianteeman Barcode scanning still doesn't work, but manually entering account and key works for adding the account to the app, and then all works as expected. So maybe the Google Authenticator app for iOS has a check for the barcode which it doesn't have for manually entered data, and maybe the app for Android behaves different? Or maybe we have different app versions and mine has a bug? But I don't see there is an update for it.

It probably needs the space to be replaced with %20 but I can't test

I have big family day today because it's my mother's 94th bday, and tomorrow I'm back at work, so I'm not sure when I can continue with testing, but I will. Btw. happy new year.

It probably needs the space to be replaced with %20 but I can't test

@brianteeman You are right. The following works for me:

		// These are used by Google Authenticator to tell accounts apart
		$username = Factory::getUser($user_id)->username;
		$sitename = Factory::getApplication()->get('sitename');

		// Encode sitename according to RFC 3986 for the QR code URL
		$sitenameEncoded = rawurlencode($sitename);

		// This is the URL to the QR code for Google Authenticator
		$url = sprintf("otpauth://totp/%s/%s?secret=%s&issuer=%s", $sitenameEncoded, $username, $secret, $sitenameEncoded);

In the user configuration in Joomla and in the authenticator app the spaces are shown as spaces.

When using $sitename = rawurlencode(Factory::getApplication()->get('sitename')); instead of the above solution, %20 is shown in Joomla in the "Account" field, that is not nice.

And when encoding the complete URL using $url = rawurlencode(sprintf("otpauth://totp/%s/%s?secret=%s&issuer=%s", $sitename, $username, $secret, $sitename));, the QR code scanning fails again.

So it seems the above solution is it, encode the issuer and author parameters only (which in our case both are the site name), and this fits to what Google write here: https://github.com/google/google-authenticator/wiki/Key-Uri-Format. They also say these parameters have to be encoded according to RFC 3986, that's why rawurlencode works and urlencode doesn't work.

@richard67 I just logged back in to say please check my update and then I saw you submitted a patch. Please check my update and if no good I will test with yours

@brianteeman I had tested same change as yours but problem was that in the user edit form in the 2fa tab, the "Account" was shown with %20 instead of the spaces.

I have tested this item ✅ successfully on b8217e9

@brianteeman For making drone system tests pass it might be necessary that you use the "Update branch" button. Reason is that it might need my recently merged change on .drone.yml.

Same for the other PRs.

Hmm, drone mysql system test still failing ... then it might be the usual, randomly occurring timeout problem.
Sorry for disturbing.

I have tested this item ✅ successfully on 9d7debb

What's the reason to have the sitename 2 times?

Test with android success full

What's the reason to have the sitename 2 times?

The first is a title (its not supported everywhere)

Thanks!

Thanks @wilsonge