Account lockout and legacy throttling

UserStore provides permanent account lock, temporary account lock, progressive throttling, and CAPTCHA. These established controls remain available after layered abuse protection is activated.

Why several controls are necessary

Each control solves a different problem:

Control	Primary purpose	Important trade-off
Progressive throttling	Makes repeated guesses slower.	Holds requests while delaying and does not stop distributed spraying.
Temporary lock	Gives an attacked account time to recover automatically.	An attacker can temporarily deny service to the user.
Permanent lock	Stops further attempts against a confirmed high-risk account.	Requires administrator intervention and can be abused for denial of service.
CAPTCHA	Separates automated traffic from an interactive user.	Requires an accessible alternative and provider availability.
Layered abuse protection	Detects account, identifier, network, tenant, and system patterns across nodes.	Requires a conforming distributed state store in multi-instance deployments.

For internet-facing and multi-instance deployments, use these controls together with layered abuse protection. Account lock alone does not stop password spraying across many users.

Permanent account lock

A user is permanently locked after the configured number of consecutive failed password attempts when that user's IsUserLockEnabled property is enabled. An administrator must unlock the user.

Option	Valid values	Default
AttemptsBeforeUserLocked	Non-negative integer; 0 disables	7

A successful password login resets the failed-attempt counter. Invalid persisted values are logged and permanent lock is disabled until corrected; temporary lock and throttling continue independently.

Denial-of-service risk

Do not use permanent lock as the only abuse control for a public application. An attacker who knows a login name can deliberately lock the account.

Temporary account lock

Temporary lock rejects all password attempts, including a correct password, until the duration has elapsed.

Option	Valid values	Default
TemporaryLockEnabled	Boolean	false
TemporaryLockThreshold	Positive integer	5
TemporaryLockDurationSeconds	Positive integer	3600

Temporary and permanent lock use the same established failed-password counter. Configure the permanent threshold above the temporary threshold if both are active.

For most customers, a 5–15 minute temporary lock is less disruptive than the one-hour compatibility default. Validate the chosen value against helpdesk and abuse-response requirements.

Progressive throttling

Legacy throttling increases the delay with consecutive failed password attempts:

delay = min(BaseDelayMs × 2^(failedAttempts - 1), MaxDelayMs)

Option	Valid values	Default
ThrottlingEnabled	Boolean	false
ThrottlingBaseDelayMs	Non-negative integer	1000
ThrottlingMaxDelayMs	Non-negative integer	30000

This delay is distinct from AbuseMaximumDelayMilliseconds, which caps distributed layered decisions.

Lock-state feedback

When a correct password is submitted for a locked account, ProAuth can either explain the lock or return the same generic message used for invalid credentials.

Option	Values	Default
InformAboutLockAfterSuccessfulLogin	Boolean	true

Set it to false for public or penetration-test-hardened deployments to avoid confirming that an attacker guessed the correct password. Keeping it true can reduce support requests in internal environments.

CAPTCHA

Use CaptchaActivationMode and CaptchaFailureThreshold to decide when password login requires a challenge. CaptchaProvider, CaptchaSiteKey, and CaptchaSecretKey configure the provider. The obsolete CaptchaEnabled value remains readable for compatibility but should not be used for new configuration.

Layered Challenge decisions feed the same password-login CAPTCHA path. A missing provider configuration fails safely rather than silently allowing the attempt.

Recommended baseline

Deployment	Starting point
Public consumer	Activate layered defaults, enable CAPTCHA, set InformAboutLockAfterSuccessfulLogin=false, enable a short temporary lock, and consider disabling permanent lock if denial of service is a greater concern.
Workforce	Activate layered defaults, enable progressive throttling and a short temporary lock, and tune network/tenant capacity for office NAT or VPN traffic.
Privileged or regulated	Use layered defaults, CAPTCHA, temporary lock, explicit hard block for confirmed compromise, lock notifications, and alerting. Permanent lock can be appropriate when the response process is staffed.

Configure options

These are UserStore IDP-instance options. Configure them in AdminApp, through Management API v2 option resources, through generated v2 clients, or with ProAuth CLI configuration import.

POST /api/management/v2/option
Content-Type: application/json

{
  "name": "TemporaryLockEnabled",
  "value": "true",
  "applyToIdpInstanceId": "<idp-instance-id>"
}

The server validates runtime values. Test threshold relationships and user-visible behavior in a non-production instance before applying them broadly.

Infrastructure protection

Application controls protect identities and recovery journeys. A trusted reverse proxy, load balancer, CDN, or WAF should also limit connections and requests to protect CPU, memory, network, and PBKDF2 capacity.

Configure forwarded headers only from trusted proxies; layered network dimensions are ineffective if an attacker can supply the apparent client address.