How to stop AI-driven login attacks

What is credential stuffing?

Credential stuffing is an attack where software tries username and password pairs from one site’s data breach on other sites’ login pages. OWASP describes it as trying credential pairs that were stolen when some other site was breached. It works because people reuse passwords, so a leak at one service becomes a way into another. The glossary entry gives the short definition.

Automation does the heavy lifting. A script can try far more pairs than a person could, and it can spread them across many IP addresses, so no single busy address gives the attack away. The explainer on bots and scrapers shows what these attempts look like in your logs.

Which defence matters most?

Two-factor sign-in matters most. OWASP says multi-factor authentication is by far the best defence against most password attacks, because a stolen password alone no longer opens the account. Turn it on for staff, admins and customers where you can.

OWASP also suggests a lighter version for customer-facing sites: ask for the second factor only when a login looks risky, such as a new device, a known proxy, or a pattern that looks scripted. You can still require it for high-risk actions, like changing a payout account.

How do you stop leaked passwords being used?

Block passwords that appear in known breaches when people create or change them. NIST SP 800-63B says new passwords must be compared with a blocklist of common, predictable or already-breached passwords, and that a user who picks a blocked one must be told why and choose another. NIST also says to drop composition rules (such as “one symbol, one capital”) and to stop forcing periodic changes unless compromise is suspected.

You do not need to build the list. Pwned Passwords offers a free range search with no API key. Your site sends only the first five characters of the password’s SHA-1 hash, receives matching hash endings and checks locally. The full password never leaves your server. Check after the user finishes typing, not on every keystroke, since Have I Been Pwned warns that live checks can expose the password to observers.

Length helps too. NIST sets a minimum of 15 characters for passwords used alone and 8 when the password is only one part of multi-factor sign-in, and says systems should allow at least 64 characters and permit pasting from password managers.

How should rate limiting work?

Rate limiting caps how many requests can hit your login in a set time, then applies an action such as blocking. Cloudflare’s rate limiting rules let you choose what to count (IP address, headers, cookies, country and more), a time period, a threshold and how long the block lasts. Cloudflare names login protection as a typical use. Its free plan includes one rule with a 10-second counting period.

Do not rely on one simple limit. OWASP warns against a single predictable volume limit and against blocking IP addresses as the main defence. Combine short bursts and long periods, make blocks temporary, and respond in stages, for example a CAPTCHA first and a block second.

Rate limits also cover your own users. NIST says consecutive failed attempts on one account’s authenticator must be capped at no more than 100 before it is disabled. Lower is fine, and small sites usually pick far less, such as 5 to 10 before a delay or a challenge. That figure is a practical choice, not a NIST number.

When should you add bot checks?

Add bot checks only for logins that look automated. OWASP says CAPTCHAs are not perfect and recommends showing them to suspicious logins only, while monitoring solve rates for signs of automated solving. It also lists device and connection fingerprinting, which can spot unfamiliar clients, while noting that attackers can spoof some fingerprints.

A web application firewall or CDN bot filter usually supplies these checks. If you run WordPress, the same tools protect wp-login.php, covered in the WordPress security checklist.

What is a sensible order to do this in?

Work from the cheapest, highest-impact step down.

1. Turn on two-factor sign-in for admins and staff today.
2. Reject known-breached passwords at sign-up and password change.
3. Add rate limits on the login and password-reset pages.
4. Add risk-based second factors and bot checks for customers.
5. Alert users about unusual sign-ins, as OWASP recommends, and watch failed-login counts so you notice a spike.

If your login page also serves an API, apply the same limits there. Automated tools can call the endpoint directly and skip the web form.

What else raises the cost for attackers?

Several smaller measures add up. OWASP lists these among its additional controls:

• Multi-step login flows: splitting the username and password across two screens makes automation harder, as long as the flow does not reveal which usernames exist.
• JavaScript and headless-browser checks: requiring JavaScript raises the attacker’s cost, though blocking users who turn JavaScript off can harm accessibility.
• Unpredictable usernames: many breach lists hold only email addresses, so a username that is not an email address makes reuse harder.
• User notifications: tell people about unusual security events, such as a login from a new device.

Each defence should also produce numbers you can watch, such as failed logins per hour, so a spike prompts a look. Pick the measures that fit your customers. A shop with many casual buyers may prefer risk-based checks over forcing everyone through two-factor sign-in on every visit.