Login pages that resist guessing: rate limits and lockouts

Yesterday we saw how a site should store passwords so a stolen database is hard to use. But attackers don’t always need the database. Sometimes they just go to the login page and start trying.

A login form is a door that answers every knock with “yes” or “no”. Without limits, it will answer millions of knocks a day. Today is about how sites make that door much harder to work through.

Three kinds of guessing

Automated login attacks come in a few flavours, and each needs a slightly different defence:

• Brute force: one account, many passwords. Try 123456, then password, then qwerty, and so on down a list.
• Password spraying: many accounts, a few common passwords. Try Summer2026! against every username, which stays under any per-account limit.
• Credential stuffing: username and password pairs leaked from other sites, tried here in bulk. This works because people reuse passwords, and it’s the most common of the three today.

All three rely on the same thing: being able to try a lot, quickly, without anyone noticing.

Why it matters for security

Every successful guess is a full account takeover. The attacker gets in with a real password, so to the site it looks exactly like a normal login. For credential stuffing, success rates are small, often well under one percent. But across millions of attempts, even a tiny rate means thousands of compromised accounts.

The goal of today’s defences is to make guessing slow, noisy and expensive enough that it stops being worth it.

Rate limiting: slowing everyone down a little

Rate limiting caps how many login attempts are allowed in a time window. A real person rarely mistypes their password more than a few times. A script wants to try hundreds per minute.

Good rate limits look at more than one thing:

• Per account: for example, five failed attempts on one username within fifteen minutes.
• Per IP address: many failures from one address across different accounts suggests spraying.
• Overall: a sudden spike in failed logins across the whole site is a signal on its own.

When a limit is hit, the server replies with 429 Too Many Requests (we met it on Day 2) or quietly adds a delay. Delays that grow with each failure, like 1 second, then 2, then 4, are very effective: invisible to a person who mistypes once, crippling to a script.

Lockouts: powerful but double-edged

The classic defence is to lock the account after a number of failures. It does stop brute force. But it has a nasty side effect: anyone who knows your username can lock you out on purpose, again and again.

So modern guidance prefers softer versions:

• Temporary lockouts that lift after a few minutes, not permanent ones that need a support call.
• Step-up checks instead of a hard lock: after several failures, ask for a CAPTCHA or an email confirmation.
• Notify the real user when their account sees repeated failures, so they know to act.

The other defences that make a difference

Rate limits are one layer. These work alongside them:

• Two-factor login. Even a correct password isn’t enough on its own. This single step defeats most credential stuffing.
• Checking new passwords against known breaches. Services like Have I Been Pwned’s Pwned Passwords let a site reject passwords that already appear in leak lists, without the password ever leaving the server in readable form.
• Generic error messages. “Incorrect username or password” is better than “No account with that email”, which tells an attacker which usernames exist. The same goes for sign-up and password reset pages.
• Bot detection. Signals like impossible typing speed, headless browsers or thousands of logins from a data centre help separate scripts from people.
• Alerts on new logins. An email saying “new sign-in from a new device” turns a silent takeover into one the user can stop.

Getting the balance right

Every login defence trades a little convenience for safety. A few rules of thumb keep the balance sensible:

1. Real users should almost never notice the defences. If they do, the limits are too tight.
2. Prefer slowing down over shutting out.
3. Treat repeated failures as a signal to watch, not just a counter to block.
4. Log failed logins and look at them, or at least alert on spikes. We’ll come back to this on Day 25.

What you can do today

If you use websites:

1. Use a unique password for every site. Credential stuffing only works on reused passwords.
2. Turn on two-factor login wherever it’s offered, starting with email, banking and social accounts.
3. Don’t ignore “new sign-in” emails. If it wasn’t you, change your password and log out all devices straight away.

If you run a website:

1. Add rate limiting to your login, sign-up and password reset endpoints. Most frameworks and hosting firewalls have it built in.
2. Use temporary lockouts or step-up checks rather than permanent lockouts.
3. Make your error messages the same whether the username exists or not.
4. Offer two-factor login and consider checking new passwords against breach lists. The OWASP Authentication Cheat Sheet and Credential Stuffing Prevention Cheat Sheet cover the details.

Coming up next

On Day 10 we’ll return to the session cookie from Day 3 and go deeper: sessions done right, with every cookie setting explained and the server-side habits that keep a logged-in user safe.