There should be a lockout mechanism in place or throttling against such bruteforce attack.

There is configuration option $g_max_failed_login_count that should do the job. Do you agree?
https://mantisbt.org/docs/master/en-US/Admin_Guide/html-desktop/#admin.config.signup

Atrol, Thanks this does the job. Aside I believe this should be enable by default as a best practice.

I believe this should be enable by default as a best practice

As always there are pros and cons.
If it's enabled, attackers could make accounts invalid by trying passwords, so users would be forced to reset their password.

I would tend to agree with @randomdhiraj that we should change this default from OFF to some fixed value - threshold can be discussed, but 5 seems reasonable.
In my opinion, it's better to force users to reset their password, than risking to have their account hacked without their knowing about it.

Thanks Dregad & Atrol.

@dregad I don't think we should lock the user account forever when an attacker attempts to attack them. I wonder if we are better off using the tokens_api to have a temporary block.

We introduce a token type ACCOUNT_LOCKOUT_IPS which has a lifetime of 5 minutes and its value is an array of IP addresses.

1. If such token doesn't exist, do regular behavior.
2. If failed login threshold is reached, create token and add the IP to the token valid (as part of a json array).
3. If a login attempt happens and IP not in the token, then check password, if invalid, add to token. If correct, then delete the token and sign in successfully.
4. If a login attempt happens from IP in the token, then fail automatically without checking password.
5. On a successful login, reset the failed login count.

I'm referring to the API in tokens_api.php.

Also changeo of this behavior is better done in a proper release and not a patch release - this may be the intention but it is hard to tell without having a specific cherry-pick commits or a PR for 2.24.x vs. master-2.25 for example.

Thanks for the feedback Victor.

Also changeo of this behavior is better done in a proper release and not a patch release - this may be the intention but it is hard to tell without having a specific cherry-pick commits or a PR for 2.24.x vs. master-2.25 for example.

Apologies, I forgot to set the target version, have done it now (2.24.4).

The current, lockout is how the system has been working until now (assuming the admin has set $g_max_failed_login_count > 0), and this has never caused any issues. Considering that the user can unlock the account themselves by following the usual password change mechanism, I think the increased security we get by changing this config's default is a minor change that definitely fits in the scope of a hotfix release.

Admins relying on external authentication (e.g. LDAP) can -- and should -- set this to zero; maybe I can update documentation to reflect this (and mention that under $g_login_method too).

Temporary lockout would be a nice feature, but that's not something I would implement as part of a security release. I have opened #27741 to track this for later implementation.