Confirmation forms should not require passwords

It looks like to me the patches may have deviated from the original issue and are not on topic, as such I am marking them hidden in an attempt to re-focus this issue.

While the patches do not appear to be very relevant in case they inspire work going forward I will note that personally I am not supportive of the hard coded special treatment for UID 1 nor the "bypass password confirm" as they both reduce security for a task that should require confirmation.

I think that either password or any enabled plugin should be good enough for these confirmation pages. Maybe allow the site administrator to choose: that would cover the case where password authentication is not a valid option.

This is probably the solution we need for now. An enabled plugin is actually probably better than password as it prevents a person who obtains the single factor from making changes.

I imagine the edge case is the scenario of an external user that has not setup TFA and doesn't have a local password. For this aspect, what if we switch to using the user.auth service instead of the password service? That way LDAP (and similar) could decorate the service and provide authentication that TFA could use. Quick glance it doesn't appear the LDAP module currently does decorate the user.auth service however if we convert TFA a followup Feature Request could than be sent to them to do so.

That probably doesn't solve SAML because of its fully off host nature probably would require us working in combination with the SAML modules to provide some standardization to the process.

Intended to set Needs Work as part of last post.

I agree that it would be more desirable to prompt a re-authentication with which ever auth plugin they used to sign in with rather than to provide a "bypass password confirm" permission.

In the scenario described in the original post, the person logging in as User 1 will still not be able to perform this action since they probably don't even know what random string was generated for User 1's password in the first place. Perhaps the solution for that level user is a drush command?

FWIW: The systems where I'm running into this issue I am using OpenID Connect connecting to an oAuth Server, not LDAP.

In the scenario described in the original post, the person logging in as User 1 will still not be able to perform this action

Hmm, fair point, and that is a tricky one as well similar to not having any way to internally authenticate them.

Perhaps the solution for that level user is a drush command

This actually may be the best method, we already allow admins with the appropriate permissions to provision a token for a user, adding a Drush command that allows provisioning from the CLI seems reasonable in that regard and would help us solve the issues.

Combining converting the forms to use a token when one is set (otherwise use password) it seems like this would be a very reasonable change and might actually increase overall account security at the same time.

I would suggest we create a seperate issue for the Drush command and leave this one just to change the form so we can discuss and commit each independently.

Actually, there are two scenarios where the password form is triggered.
1. To set up TFA at user//security/tfa/ga_login_totp
2. To disable TFA at user/

This patch disables the password form for uid 1 on both the above-said scenario. This patch is created for 1.8 version.

Adjusting tags as this needs updates per #14 and #17

Not treating UID:1 as special becomes even more relevant now that 📌 Add a container parameter that can remove the special behavior of UID#1 Fixed is into core.

Switching the form to use the Core authentication service and offering an OTP when one is configured seems like our best solution.

SSO users we can't really solve via the UI and fallback to a drush command seems best.

✨ Provide drush command to reset a user's TFA data Fixed was already added as one example of administrative commands in Drush.

As an aside, D.O. has migrated away from the patch workflow. More details on contributing to issues on D.O. using MR's may be found at https://www.drupal.org/docs/develop/git/using-gitlab-to-contribute-to-dr... →

Hiding repeat patch in #22 to avoid future confusion.