Allow trusted user accounts to bypass the per-IP login delay

[computertech1012]

Hi,

I would like to suggest adding an account permission that allows a trusted user account to bypass the server's login delay per IP address.

The existing IP-based delay is useful for guests, invalid credentials, and abusive connections. The problem is that several legitimate clients can share one public IP address. For example, a personal TeamTalk client, an unattended radio client, and several bots may all be behind the same router. If the connection drops, all of them try to reconnect together. One successful login starts the IP delay, and another legitimate client using a different account can then receive a flood error even though that account did nothing wrong.

Using different loopback addresses helps when every client runs locally on the server, but it does not solve remote clients behind the same NAT connection. Making the delay username-only would also have disadvantages: guest users can share one account, and an attacker could rotate usernames. Because of that, I do not think username-based protection should replace IP protection.

My suggestion is:

• Keep the existing server-wide login delay per IP address as the default.
• Add a user-account right such as "Bypass login delay per IP address" for trusted service accounts.
• Check this right only after the account has authenticated successfully. Invalid credentials would still be subject to the normal IP protections.
• Anonymous and guest accounts would continue using the normal IP delay unless an administrator explicitly gives that account the bypass right.
• Consider automatically exempting administrator accounts, since administrators are already exempt from the server's maximum-logins-per-IP check.

This would let server owners protect public access without accidentally blocking their own trusted bots and radio clients during a simultaneous reconnect. It would also be safer than a global switch because the exception would only apply to accounts chosen by the server administrator.

There is an older discussion about limiting simultaneous logins per username in #1636. That is related, but this request is specifically about preventing trusted accounts on a shared IP address from interfering with each other's reconnect delay.

I would be willing to work on a pull request if this approach makes sense. @bear101, would a per-account user right be acceptable, or would you prefer this to be implemented as a per-account login-delay value?

Thanks for reading!

[computertech1012]

Hi,

I opened #3442 with the narrower administrator-only approach: accounts with user type 2 bypass the per-IP login delay, matching the existing administrator exemption from the maximum-logins-per-IP limit.

Ordinary accounts remain subject to the delay, and invalid credentials and banned accounts are unchanged. The administrator check happens before the delay tracker, so administrator logins do not create or refresh the IP timestamp.

I built both server variants and ran 20 focused Standard and Professional-client test passes before opening it.

@bear101, the pull request is here: #3442

Thanks for reading!

[bear101]

Why should administrators be exempt from this delay? Should they also be exempt from bans?

Exemptions from rules make things more complicated.

[computertech1012]

Hi,

The reason is to preserve access for a correctly authenticated administrator when the automatic delay was triggered by other sessions sharing the same public IP address.

The distinction I am proposing is between an automatic shared-IP throttle and a deliberate access policy. nLoginDelayMSec is evaluated after successful authentication and uses a sliding timestamp for the source IP. This means one legitimate session behind shared NAT can delay a different, correctly authenticated administrator.

TeamTalk already exempts user type 2 administrators from the maximum server-user limit and maximum logins per IP. Without the same narrow exemption here, the earlier time-based IP throttle can defeat those existing exemptions before the administrator is accepted. That is the inconsistency this pull request addresses.

No, I am not proposing blanket ban immunity in this pull request. Bans are deliberate access-control decisions and remain enforced during authentication. Invalid credentials are also unchanged and continue through the existing failed-login protections. The tradeoff is that someone holding valid administrator credentials can reconnect rapidly, but those credentials already provide full server authority.

The implementation is only one authenticated user-type check before LoginsExceeded(). It adds no setting, persisted state, protocol field, or client change.

@bear101, I hope this explains why I believe this narrow exemption is consistent with the administrator behavior that TeamTalk already has.

Thanks for reading!