I see two mitigations of type “throtting”, a simple one and another slightly more complex.

I. Simple: implement a per-IP authentication throttling for failed logins:

Currently the throttler for authentications (MediaWiki\Auth\Throttler and MediaWiki\Auth\ThrottlePreAuthenticationProvider::testForAuthentication()) only limits throttling per-IP-and-account and per-account, but not per-IP for all accounts. This could be easily implemented by adding a 'allAccounts' keyword in the config $wgPasswordAttemptThrottle.

A difficulty here is the question: when and how the data should be cleared:

• reset to 0 for the IP in case of successful login; but is it a legit user or a password-spray attack finding a low-entropy password?
• decrement the counter of a given number (e.g. N=2) to slow down the password-spray attack but still avoid too much false positive like an edit sprint with many newcomers behind the same IP in a museum/library?
• do not clear this counter (same as previous one with N=0) and let it expire when the period is over, this is more strict

This number N (nonnegative integer or Infinity to reset the counter) could be a parameter 'strictness' or whe can fix it in the code.

II. Use more data in the throttling logic like User-Agent:

Currently the throttling logic in MediaWiki\Auth\Throttler::increase() has only a knowledge of the username and IP. According to Microsoft, the User-Agent is sometimes a fixed value/fingerprinting method during a password spray attack. Given the variability in User-Agent strings and the evolving threat, I’m not sure it would be a good design decision to fix a given scenario with the User-Agent and implement a fixed configuration with one or some scenarii, but I would propose here to add a hook with the whole HTTP request.

With a hook, sysadmins can define their own scenarii, and it can evolve more quickly and easily according to the threat. For instance and depending on their infrastructure, they can compute JA3 fingerprints or other fingerprints of known password sprays softwares and integrate more deeply MediaWiki with other security tools.

Triaged by the Security-Team during our clinic. This seems more like a code-hardening effort/new feature request, so it can be made public.