Account Banning

Account banning is the per-user counterpart to IP banning. It tracks failed sign-in attempts per username rather than per source IP. The distinction matters because a clever attacker rotates source IPs but only tries one or two known usernames.

Why You Want Both Layers

• IP banning catches the “try thousands of passwords against one account from one IP” pattern.
• Account banning catches “try a few passwords against one account from rotating IPs” — the more sophisticated attacker.
• Together they cover most credential-stuffing patterns.

The Three Knobs

• Attempts: Number of failures within the window to trigger a block (typically 5).
• Monitoring period: Window over which attempts are counted (typically 15 minutes).
• Ban duration: Block length (typically 30 minutes; admin unblock available).

What Happens When Banned

• The user (or attacker) sees a generic “Sign-in temporarily unavailable for this account, try again later” message.
• The user is added to the blocked accounts list with reason “auto”.
• If configured, the real user receives an email alerting them that their account has been locked due to failed attempts.
• After the ban duration elapses, sign-in works again. The failed counter is reset.

Worked Examples

• Credential stuffing detected: One username, 5 attempts from 5 different IPs over 12 minutes — account banned. The user logs in fine 30 minutes later.
• Stolen list: Attacker uses a stolen email list; every targeted account hits the threshold within hours. All locked; users notified.
• Forgetful user: Same person mistyping their password 5 times — they get the lockout message; their email arrives with a reset link they can use immediately.

Note: Always pair the lockout message with a password-reset link in the lockout email. Otherwise legitimate users get stuck and call support.

The right thresholds balance security (catch attacks early) with usability (don't lock out fat-fingered users repeatedly). This article shares the levers and recipes by audience.

Default Recipe

• Attempts: 5
• Monitoring period: 15 minutes
• Ban duration: 30 minutes
• Email user on lockout: Yes

Tightening Recipes

• Admin accounts only: Attempts 3, monitoring 60 minutes, ban 24 hours, require manual unblock. These accounts shouldn't be brute-forced under any circumstances.
• Financial services: Attempts 4, monitoring 30 minutes, ban 1 hour. Include passkey enforcement.

Loosening Recipes

• Public consumer app: Attempts 8, monitoring 30 minutes, ban 15 minutes. Most users will mistype before remembering or hitting reset.
• B2B with password-manager users: Attempts 6, monitoring 10 minutes, ban 30 minutes. Users either know their password or use the manager; few mistakes.

Combining Account + IP

Set IP attempts higher than account attempts. Reason: a single user hitting their account ban shouldn't also burn the IP ban — they have legitimate reason to try again later.

Worked Examples

• Healthcare admin portal: 3 attempts, 60 min monitoring, 24 hr ban with manual review.
• Consumer marketplace: 8 attempts, 30 min monitoring, 15 min ban — generous but enough to deter automation.
• API user accounts: 10 attempts on the auth endpoint, 5 min window, 30 min ban — handles bursty mistakes from misconfigured integrations.