Adopt a 'security first' focus

I don't see anything actionable here. Even with as many flaws as the module may have, since it is hacking into Drupal's user login workflow which was not designed to be extendable, the current code already tries to ship with secure defaults, and to forbid login.

I know what you are really talking about, but I think that without a major drive from to have 2FA or at a least a more extendable login process in Drupal core, the policy that you are requesting is the same as: "Please re-implement all the user login functionality in the module, and while at it remember to re-implement every other core service that deals with user authentication". It is honestly not too far away from "please maintain a fork of Drupal core".

So my question to you is... Do you want to be a co-maintainer and do this yourself?

a maintainer has expressed a preference that reducing the number of support requests

It is not about reducing the number of support requests.. It's about reducing the effort necessary to maintain the module, of which there is sincerely very little capability at the moment.

To be honest, with this particular issue I really am intending on focusing on the secure defaults, that when were adding new features, and were evaluating the road-map for the future that we choose the methods that make TFA as secure as it can be (for example ✨ Disallow viewing recovery codes after first display Active the change would be that we would instead of preferring to allow recovery codes to be visible by default, we would prefer that they not be viable by default).

I know what you are really talking about.... So my question to you is... Do you want to be a co-maintainer and do this yourself?

We do have that other side discussion that I would like to see move forward though that honestly wasn't the primary driver for this issue, more I wanted to see if I should start submitting other restructurings as part of 2.x that will increase developer effort where we restructure from 'assume everything is working" to "assume nothing is working" in efforts to harden parts of the code that maybe never actually pose an issue but we can reduce the risk so that should those incidents ever happen its already mitigated.

That said yes I am willing to co-maintain and push through these additional tasks, and the other side tasks we have discussed, along with helping clear out the current queue in order to bring TFA to a more solid footing.

I believe we can consider this issue 'fixed'.

Automatically closed - issue fixed for 2 weeks with no activity.