Protect preventing authentication flows for .org two-factor

[georgestephanis]

Impacted plugin

Protect

Quick summary

Protect seems to be blocking some reauth flows for the WordPress.org Two Factor extension:

WordPress/wporg-two-factor#332

I've already done some minor debugging work on it, trying to trace the messages. There's more context in .org slack here:

https://wordpress.slack.com/archives/C02RP4Y3K/p1767886583819919

My /suspicion/ is that it's due to a flow with custom login page actions -- Protect manually handles them by return;-ing when it's a logout request but there's no matching filter to enable other plugins from short circuiting the kill -- I'm not positive if it'd resolve the issue, but it feels like a filter there would be worthwhile to let other plugins override it if it's an edge case.

Steps to reproduce

Reauth in two-factor flow triggered failure.

Site owner impact

Fewer than 20% of the total website/platform users

Severity

Major

What other impact(s) does this issue have?

No response

If a workaround is available, please outline it here.

Issue seemed to clear itself when the user's IP likely fell off the bruteprotect ip rolls, but if this is the instance we've heard about, there's probably more.

Platform (Simple and/or Atomic)

Self-hosted

[ArSn]

Hi, if an IP has been blocked, then there is probably a good reason for it (usually, too many attempts with wrong credentials).

Of course there can be some exceptions, like large networks that go through the same IP to the internet, such as universities, but in general, it seems like a good thing that this is blocked if the IP "misbehaved"?

What would be the rationale for opting out of the (legit, unless we know otherwise) block in some cases?

[georgestephanis]

It's not so much that it's blocking, it's that the flow seems to be triggering when it shouldn't, so it's impossible to actually get past it with the methods offered.

[ArSn]

Not getting past it is precisely the point of Brute Force Protection if you (or your IP) have been identified as a potential malicious actor.

I realize at this point there is "only" a 2FA auth happening, but wouldn't you agree that this would precisely be the moment where stolen or phished credentials could be entered?

I've also asked the team, and we don't see a strong argument to change the existing behavior at this point, especially given that the issue resolved itself by the IP rolling off the block list, as it should.