[BUG] Username enumeration possible if lockout enabled #240

Describe the bug

The /users/_login endpoint reveals whether a username exists in the system by returning different error messages and statuses based on the account's state. Specifically, when password retry limits are enabled, the API response for a valid username includes a "login attempts remaining" counter or a FAIL_LOCKED_OUT status. A non-existent username returns a generic failure. This allows an attacker to distinguish between valid and invalid usernames (Account Enumeration).

To Reproduce

1. Enable account lockout features in Mirth (e.g., set _MP_PASSWORD_RETRYLIMIT to 5).
2. Attempt a login with a non-existent username (e.g., notARealUser).

• Response: Returns generic FAIL with "Incorrect username or password."

3. Attempt a login with a known valid username (e.g., admin) and an incorrect password.

• Response: Returns FAIL but includes specific metadata: "2 login attempt(s) remaining for "admin"..."

4. Continue failed attempts on the valid username until the limit is reached.

• Response: Returns FAIL_LOCKED_OUT and a message confirming the account is locked for a specific duration.

Expected behavior

To prevent account enumeration, the server should return an identical response (Status Code, JSON Body, and Response Timing) regardless of whether the username exists, the password is incorrect, or the account is currently locked.

The recommended response is a generic:
{"status": "FAIL", "message": "Invalid username or password"}

Actual behavior

The API discloses the existence of valid accounts through specific error strings and the LoginStatus enum:

• Valid User/Bad Pass: Discloses remaining attempts.
• Locked Account: Discloses FAIL_LOCKED_OUT and the time remaining.
• Invalid User: Returns a generic failure with no attempt counter.

Workaround(s)

1. Disable Lockout/Retry Limits: Reverting to default settings (where these are off) stops the specific counter disclosure, though it increases the risk of brute-force success.
2. Network Restrictions: Do not expose the Mirth API/Administrator port to the public internet; restrict access to a management VPN or trusted IP range. Use a WAF or other security appliance to limit username enumeration.
3. External Auth: Use a federated identity provider so Mirth is not handling the credential validation logic.

Reported by Michael Hobbs