Can't disable user's 2FA

[hottakes]

When logged in as admin, there's a setting to disable a user's 2FA, but it doesn't do anything. 2FA stays enabled.

I tried it on a clean SMF 2.1.3.

[Diego Andrés]

Are you referring to this setting?:

You cannot view this attachment.

[Diego Andrés]

I tested with the following steps:

• Enabled 2FA in both Admin account and Test account
• Went to Test's profile > Account configuration > Disable 2FA

• Enabled 2FA in both Admin account and Test account
• Disabled 2FA from the main/master setting

None of them gave me any issues.

[Aleksi "Lex" Kilpinen]

I have done this to a live user as well without issues.

[Steve]

As this is not a bug, moving to Support.

[Aleksi "Lex" Kilpinen]

At the very least, there is something different in the OPs case. Now if we just knew what that is, might help figure this out.

[Doug Heffernan]

When logged in as admin, there's a setting to disable a user's 2FA, but it doesn't do anything. 2FA stays enabled.

I tried it on a clean SMF 2.1.3.

I couldn't reproduce this either. Did this happen for a particular user? WHat mods do you have installed?

[live627]

* live627 grumbles about low quality bug reports

[hottakes]

Are you referring to this setting?:

You cannot view this attachment.

No, I mean this, in Profile - Account Settings:
You cannot view this attachment.
Clicking on "Disable" makes the page reload quickly and that's it.

This problem only happens if I do it as the Admin to a user. If I log in as that user, I can disable my own 2FA no problem.

Did this happen for a particular user? WHat mods do you have installed?

No, it happens for any user that I add. No mods installed, except "SMF 2.1.3 Update".


Since it looks like nobody can reproduce it, I guess it's caused by something in the server. I'm hosting this for testing on a free provider AeonFree [nofollow], with their free subdomain. I just installed SMF with CPanel's automatic tool and added SSL too.
I know these free providers have some limitations, they can't send out emails for example. But 2FA does work for logging in, so IDK.

[hottakes]

More info:
There are no errors logged.
I can reproduce this on a different SMF install by the same free hosting provider. But that one does have some mods and theme changes.


And this is from the "Php info" section of the default install:
Server API    Apache 2.0 Handler
PHP Version    7.4.8
Client API version    mysqlnd 7.4.8
SQLite Library    3.7.17
cURL Information    7.71.1
ZLib Version    1.2.3
DOM/XML API Version    20031129
libxml Version    2.7.6
OpenSSL Library Version    OpenSSL 1.1.1g 21 Apr 2020
PCRE Library Version    10.34 2019-11-21
Phar API version    1.1.1
core library version    xmlrpc-epi v. 0.51
libmagic    537



I am quite confident that I didn't do anything weird. This SMF is pretty much untouched, in fact.
But there could be some leftover from the previous installation. I had ElkArte installed there at some point.
In any case, if nobody with a "real server" can reproduce it, it's likely caused by that. It's just strange that it only happens when I try to disable it from the Admin side.

[Aleksi "Lex" Kilpinen]

Been testing now. Yes, there is something borked with this.

My test sequence, pretty much exactly:
- Install 2.1.3
- Login as admin, register a second account, do not touch admin account settings yet
- Login as second account, set up 2FA, log out
- Login as admin, try to disable 2FA for second user => Nothing happens.
- Set up 2FA for admin, then try to disable 2FA for second user => SMF tells you you are about to disable 2FA for admin.
- Click Disable anyways, you will get notification that "The profile of second user has been updated successfully. (This appears to be true, and Admin retains 2FA)

Conclusions:
1) In order to be able to disable a users 2FA, the admin MUST have 2FA set up as well - No idea why.
2) The warning message before actually doing this, doesn't recognize the edited profile correctly.
3) The 2 above may be related? Perhaps, this is a clue to why no. 1 happens.

#7699

[Arantor]

1) In order to change 2FA settings, the admin must have 2FA settings so as they can't lock themselves out by changing 2FA settings without a working 2FA to get back in.

[Aleksi "Lex" Kilpinen]

For forum wide settings, and forcing 2FA that's a valid reasoning IMO - But in this test, no 2FA settings were changed or attempted to change, the admin did not have 2FA enabled, the regular user did change settings for themselves and the admin was unable to revert that. So the user managed to lock themselves out, and the admin was unable to help.

[Arantor]

Then you have two bugs.

[Aleksi "Lex" Kilpinen]

I'm sorry, I'm not following - What are the 2 exactly? The one I see is that if a user sets up 2FA in their account, no one can turn it off without setting 2FA in their own account first. The admin settings do say that if you want to force 2FA, you need to do this, but nothing else. You can enable/disable the feature completely without setting it up for yourself. ( as a detail, I am unsure if I had manually enabled this earlier or not, but do not see it relevant. )

[Arantor]

This is predicated on the situation that User A turning off a feature for user B requires A to have the feature turned on.

1. While there is value in not force-enabling 2FA on accounts without admins having it set up ahead of time (to make sure admins are not locked out and thus able to change the configuration), there is no value in making a specific admin have it configured just to turn it off for a specific account. Worse than that, consider the situation if both A and B are admins and A doesn't have 2FA setup while B does. The only get-out options are A enabling 2FA themselves (which may not be possible) or A turning off 2FA for *everyone* to fix it for B. (That's an interesting 1a bug: you can't turn off 2FA individually without 2FA yourself but you can turn it off globally, forcibly removing any 2FA setup anyone has.)

2. Even if the feature does require A to have it enabled to alter it (in either direction) on B, this should be communicated. Whether you want to argue that this should be communicated ahead of time and not allowing the option, or communicated as an error upon trying the action, it's still a bug that the action is enabled and just apparently doesn't work without adequate feedback.

3. 2FA mode is only enforced on *login*. If you have yourself set to be logged in forever, and were logged in before this was configured, you may never have to set it up anyway. This is especially important in the situation when you look at admin; there's no push for 2FA on the session validation every hour or similar and I don't know if there should be.