Allow Drush uli login command to bypass TFA

We don't have D7 project with this module anymore so I also have no interest in a D7 version anymore. Meanwhile bypassing is possible for user-1 via config in D10 version. This was one of main reasons for me to work on this issue. Another reason is testing with different users. And before someone argues about test accounts to manage. We have a customer project with this module where the content is very focused on specific users. There it's very helpful to login as a specific user on a test system with bypassing the TFA to work on customer issues. So it would be still nice to have a "bypass flag" for Drush. When I find some time I will try to uprade the concept above to D10.

Considering ✨ Provide drush command to reset a user's TFA data Fixed is going to provide Drush command to reset TFA data which lets admin to access the user account. Should we close this as won't fix as this issue has security implications.

Admin can bypass user password requirement and login to the site without user knowing someone accessed their account. The whole point of TFA is to prevent someone accessing user account without second factor authentication.

In case someone needs this feature we can add it as sub module.

In local environments, tfa module could be disabled temporally:

drush pmu tfa -y
drush uli
[Use the link]
drush cim -y

Deactivating the module complete is not helpful in our testing situations. But because this is possible it's an argument against #49.
But anyway I like to have this feature and see no problem to realize as submodule. But so it's still an issue of the main module and should stay open.

In case someone needs this feature we can add it as sub module.

If this can be done as a login plugin or sub module than it may not actually need to go into TFA and can instead be an Ecosystem module allowing sites the option to download the code or not. This adds a layer of security in that a admin user may have ability to enable modules without having filesystem permissions to write code to the site.

cumbersome and unnecessary for those users that already have drush access to the site, providing them with God rights on the site:

I want to note that we should be very careful assuming that if Drush installed that everyone has 'god' access. Drush may be behind other security measure such as SELinux preventing file writes, settings.php hard coding config (such as TFA enabled) with no write access to override. Drush itself may be behind a sudo config that only allows certain commands, etc.

But because this is possible it's an argument against #49.

I'm not sure I agree with this. There is a significant difference between TFA being bypassed because its been removed/disabled, and TFA being bypassed because we built a feature intended to allow bypassing it.

TFA should be thought of as 'independent' of the site. If we were an external SSO system for example the idea of disabling TFA for a single login wouldn't even be considered an option because it couldn't be done.

There will always be some actions that we can't prevent occurring, however we don't have to support them either.

Deactivating the module complete is not helpful in our testing situations.

✨ Allow TFA requirement to be configured per user Needs work is closer to handling the testing subject imho. Though even that only holds validity when we use an argument that a counter based token isn't used on the site as any counter token would allow for repeated logins in short succession.

where the TFA screen on an app like Google Authenticator becomes unmanageable with a PIN for each site.

I do want to point out that I believe OTP apps have become much better over the years since this issue was opened with some having very robust organization structures.

It seems that this patch does not work with the latest TFA version.