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.