How to limit repeated customer login attempts without locking out the wrong people

Decide what repeated failures mean

A customer login form faces two different patterns. One attacker may try many passwords against a single account; another may test a small number of known passwords against many accounts. A simple per-IP cap can miss the first pattern when requests arrive from several networks, and can punish many legitimate customers sharing one network. OWASP's authentication guidance says the failed-login counter should be associated with the account rather than only the source IP. NIST's current digital identity guidance requires verifiers, where its authenticator rules apply, to limit consecutive failed attempts for a specific authenticator on one account. A Hong Kong SME can use those principles without claiming that a US government standard is itself local law.

Start by mapping every way a person can submit a credential: website, mobile app, legacy login endpoint, password reset completion, and any federated sign-in handoff. The control must act at the server that makes the authentication decision; a disabled button in a browser is not a rate limit. Record which account identifier the server resolves, which authenticator failed, when a failure is counted, and when the count is cleared. A user who mistypes an email must not silently increment an unrelated person's counter. Equally, changing letter case or using an alias must not create an unlimited fresh bucket if both values resolve to one account. Define those rules before choosing a threshold.

Choose a response that slows guessing and limits denial of service

There is no universal ‘five attempts, then freeze the account’ rule in the sources. NIST describes an upper bound of no more than 100 consecutive failed attempts for relevant authenticators, explicitly noting that lower limits may be used; that number is not a recommended setting for every shop. OWASP asks designers to balance threshold, observation window and lockout duration. A practical design may introduce a short waiting period after repeated failures, increase that wait as failures continue, and preserve an independent recovery route. The exact values need a risk decision based on account sensitivity, threat volume and how quickly genuine customers can obtain help. Publish the customer consequence, not an attacker-friendly diagram of every internal threshold.

A hard lock can become an attack in itself: someone who knows a customer's email may deliberately trigger it before the customer needs to order. Test the business impact of a lock on order history, saved bookings and urgent support. Consider whether a short delay, step-up verification or alternative authenticator provides a better route for the affected account. Do not assume CAPTCHA is a complete defence; OWASP describes it as an additional layer with weaknesses, and an inaccessible challenge can block the very customer you are trying to protect. If a challenge is introduced, test it with keyboard, screen reader and mobile users, and provide an accessible way to proceed when the challenge fails.

Make the failure message and recovery route coherent

A customer should know whether to retry later, use an established recovery route, or contact support. Write a message that explains the next action without revealing whether a guessed email belongs to an account. Keep account-existence responses suitably consistent across login and recovery entry points. If a person reaches a temporary limit, do not present a normal password error with no indication that further attempts will be delayed. If the account is disabled, the route to restore access must be real, staffed or automated as stated, and available to people who cannot receive an email immediately. Support agents need a documented way to verify the caller before clearing a restriction; otherwise the recovery route can undo the protection.

Separate a wrong password from a service outage in internal monitoring even if public messages avoid unnecessary account detail. A surge of failures on one account, a broad spray across accounts and an elevated error rate caused by your own identity provider require different actions. Log enough to investigate: time, outcome, resolved account reference where appropriate, request correlation and risk signals. Avoid logging passwords, one-time codes or full session tokens. Restrict access to the logs and define retention under the business's own policy. OWASP's credential-stuffing guidance treats defensive layers and metrics as part of the response, but it does not give a single threshold that proves safety. Monitor the legitimate customer impact as well as the attack signal.

Walk through a realistic customer case

Suppose an online retailer receives repeated failed logins for one customer's account from several networks. The account-based counter rises, so the server begins imposing a wait while continuing to reject incorrect credentials. A separate network signal helps analysts see the spread, but does not replace the account control. Later the real customer enters a correct password from home. The system should apply the documented policy consistently: if the account is merely delayed, tell the customer when to retry; if an additional check is required, make it usable; if an authenticator has been disabled, send the customer through a verified rebind or recovery path. Never silently create a new session because support believes the caller sounds genuine.

The rehearsal should also include a family or office network where several customers use different accounts, because a coarse IP limit can make an innocent group fail together. Include an account whose identifier is written with different letter case, a customer with a password manager, and a person who starts recovery while a delay is active. The expected result is not always immediate access; it is a predictable and safe path with a clear next step. Check whether successful authentication clears relevant previous failures according to the chosen policy, and whether one failed method incorrectly resets or contaminates the count for another. NIST gives specific guidance on resetting counts after success, so implementers should review the applicable authenticator type rather than copying a global counter rule.

Prove the control works end to end

Test the policy through the public login route and every alternative client, with controlled test accounts. Verify that failures are counted across devices for the same account, that different accounts do not inherit each other's counters, and that a restart or deployment does not unexpectedly erase the control. Check the user-facing message at each state in English and Traditional Chinese. Confirm the recovery route really restores access and records the event, and that support can explain the next step without revealing account details to an unverified caller. Review the effect on valid sign-ins and support tickets after release, then adjust only from observed data. The objective is to make guessing costly while keeping a legitimate path open.

Document who can change thresholds, how an emergency change is approved internally, and which signals trigger review. A login limit is operational policy as well as code: a tiny configuration change can shift a large support burden or weaken protection. Keep a versioned record of the selected values and the reason for them, without publishing exploitable implementation detail. Revisit the policy after a change to sign-in methods or a wave of account attacks. Do not claim the system is immune to credential stuffing because a counter exists; attackers can distribute attempts and use valid stolen credentials. The measurable promise is narrower: repeated failed attempts receive the designed server-side response, and customers have a tested route when that response affects them.

Before launch, decide what an operator will do when the signals conflict. For example, the same household may generate several failures because a password manager still holds an old password, while a remote attacker may produce a similar count. A support agent should not guess from the count alone. Give the team a route to check timestamps, affected accounts and the customer's own report without asking for a password. If the customer must wait, state how the wait will be communicated; if a reset is offered, ensure it does not automatically bypass the very account restriction under investigation. Rehearse one false positive and one clear attack using test accounts, then record the observed customer message, server decision and support action. That evidence is more useful than declaring the chosen threshold ‘secure’ without a tested recovery path.

A useful policy review separates prevention from response. Throttling reduces the number and speed of guesses; it does not establish that a successful sign-in is trustworthy. If an account shows repeated failures followed by a successful login from an unusual context, the business may need a separate risk response, such as notifying the account owner or asking for an established additional factor, according to its documented policy. Do not silently convert every failure into a customer alert, because a hostile actor could flood inboxes by repeatedly trying known addresses. Decide which events warrant a notification, who investigates them, and how a customer can report an unfamiliar sign-in without sharing credentials. The review should include genuine operational observations: how often legitimate users hit a delay, how many support cases required recovery, and whether distributed failed attempts are visible across entry points. Unknown measurements are unknown, not evidence that the threshold is harmless.