The App > Design > Security > User page lets you configure login brute force attack protection for your app. When enabled, the system tracks consecutive failed login attempts per user and automatically disables their account for an escalating period after each threshold is crossed. This deters automated credential-stuffing and password-guessing attacks without locking out legitimate users on a first mistake.
Enabling Brute Force Protection
Check the Enable login brute force attack protection checkbox at the top of the page to activate the feature. All rule fields and notification settings become editable once this is enabled. Uncheck it to disable protection entirely without losing your configured rules — your settings are preserved and will take effect again if you re-enable it.
Progressive Lockout Rules
The protection system uses four escalating rules. Each rule defines a threshold of consecutive bad login attempts and the duration the account is disabled as a result. The rules must form a strictly increasing sequence — both the attempt counts and the disable durations must increase from Rule 1 through Rule 4.
Each rule (except the last) is expressed as:
"After X bad attempts in a row, disable login for Y hour(s)"
The fourth and final rule is permanent:
"After X bad attempts in a row, disable login until manually unlocked by an App Administrator"
Rule 1 — the first warning threshold. Set a low attempt count (minimum: 1) and a short disable duration (minimum: 1 hour). For example: after 3 bad attempts, disable for 1 hour.
Rule 2 — the second escalation. Both the attempt count and disable hours must be greater than Rule 1's values. For example: after 5 bad attempts, disable for 4 hours.
Rule 3 — the third escalation. Both values must exceed Rule 2's. The disable hours for Rule 3 cannot exceed 160 hours (approximately one week). For example: after 10 bad attempts, disable for 24 hours.
Rule 4 — the permanent lockout threshold. The attempt count must exceed Rule 3's (up to a maximum of 99,999). There is no disable duration field — once a user hits this threshold, their account is permanently disabled until an App Administrator manually re-enables it via the User Monitoring section. For example: after 20 bad attempts, disable until manually unlocked.
The Save button is blocked if any rule's values are out of sequence. Each field shows its valid range inline as you type.
Email Notifications
If your app has SendGrid integration configured, an additional section appears below the rules allowing you to notify users when their account is disabled.
Send account disabled notifications to user's contact email (if applicable) — when checked, brainCloud will send an automated email to the user's registered contact email address each time their account is disabled by a brute force rule. The email is only sent if the user has a contact email on record.
When that checkbox is enabled, a second option appears:
Bcc this account in email — when checked, a text field appears where you can enter an email address to receive a blind copy of every account-disabled notification. This is useful for security monitoring or alerting your support team. The BCC address must be a valid email address format.
These notification settings are only visible when SendGrid is enabled for the app. If you do not see them, check your integration settings under App > Design > Integrations > Manage Integrations.
Manually Unlocking Accounts
Users who reach the Rule 4 threshold are permanently disabled and cannot log in again until an administrator unlocks them. To re-enable a locked account:
Navigate to App > User Monitoring (or User > Summary for a specific user).
Find the affected user by searching their profile ID, email, or other identifier.
Use the account enable/disable control to restore their access.
Accounts disabled by Rules 1–3 are automatically re-enabled once the disable duration expires — no manual intervention is needed for those tiers.
Actions
Reset— reverts all unsaved changes back to the last saved configuration. Disabled when there are no unsaved changes.Save— persists the configuration. Disabled when there are no unsaved changes, when validation fails (e.g. rules are out of sequence or the BCC email is invalid), or when the current user lacks write access to theDESIGN_SECURITY_USERpermission.
Permissions
Viewing this page requires the DESIGN_SECURITY_USER permission. Modifying the configuration requires write access to that permission. Users with read-only access can view the current settings but all controls will be disabled.
