Stopping password-guessing attacks on your login page

Every login page on the internet is being tried by someone’s software. Automated programs work through lists of common passwords, email and password pairs leaked from other websites, and guesses built from your site’s name, hoping one combination will open an account. On a quiet membership site you may never notice. Then one day your login page slows to a crawl, a member receives a string of password reset emails they did not request, or you find an administrator login from a country none of your team has visited.

These are password-guessing attacks, and they are among the most common threats a membership site faces. The defenses are well understood. The challenge is applying them so that attackers are stopped while your members, who also mistype their passwords, are not.

The different ways attackers guess

Each kind of attack is caught by a slightly different defense, so it helps to know them apart:

• Brute force: trying many passwords against one account, often an obvious one such as an administrator username.
• Password spraying: trying a handful of very common passwords against many accounts, slowly, so no single account sees many failures.
• Credential stuffing: trying email and password pairs leaked from other sites, relying on people reusing passwords.
• Distributed attacks: any of the above spread across many internet addresses, so no single address looks busy.

A defense that only counts failures per account misses spraying. One that only counts failures per address misses distributed attacks. Layering several defenses is what works.

Rate limits: slowing everything down

A rate limit caps how many login attempts can be made in a period of time. Check what your membership platform or host offers. Common forms include:

1. Per internet address. After a number of failures from one address, further attempts from it are slowed or blocked for a while.
2. Per account. After several failures on one account, that account needs an extra step or a pause, wherever the attempts come from.
3. Across the whole site. If failed logins suddenly jump far above normal, extra checks switch on for everyone until things calm down.

Increasing delays often work better than hard blocks. A short wait after a few failures, then a longer one, costs a genuine member a few seconds but makes guessing thousands of passwords impractical.

Lockouts: useful, but handle with care

Locking an account after repeated failures stops an attacker from continuing to guess. It also creates a new problem: anyone who knows a member’s email address can lock them out on purpose just by entering wrong passwords. For an administrator account, that could keep you out of your own site at a critical moment.

Most small membership sites are best served by temporary lockouts that lift automatically after a period, combined with the option to unlock sooner through a reset link sent to the email address on file. Permanent lockouts that need a support email to lift create frustration and extra work. Whatever you choose, tell the member plainly what has happened and what to do next.

Other defenses worth switching on

None of these helps if the login software itself has a known flaw, so start by keeping your platform and add-ons up to date. Then consider:

• Challenges after failures. Rather than showing everyone a CAPTCHA, a test designed to tell humans from bots, show it only after several failed attempts or when traffic looks suspicious.
• Blocking known-breached passwords. Some software can check new passwords against lists exposed in past breaches and refuse them, which blunts credential stuffing at the source.
• Two-factor authentication for administrators. Even if an attacker guesses an admin password, a second step stops them. Make it mandatory for every admin account.
• A firewall in front of your site. A web application firewall filters traffic before it reaches your site and can block known attack sources. Many hosts include one or offer it as an option.
• Restricting the admin area. Where possible, limit administrator logins to known locations or add an extra step. Moving the admin login to an unusual address may reduce automated noise, but treat that as a small bonus, never a defense on its own.
• New login alerts. An email to the account holder when a login succeeds from a new device helps members and admins spot a takeover quickly.

A worked example: responding to an attack in progress

Declan runs a hypothetical vintage motorcycle restoration club. One evening his host warns him that login traffic has spiked, and three members forward reset emails they never requested. Here is what he does:

1. He checks the login records in his activity logs and sees thousands of failed attempts across hundreds of member accounts, spread over many addresses: a credential stuffing attack.
2. He confirms that no administrator account had a successful login from an unfamiliar place.
3. He asks his host to apply stricter firewall rules to the login page, and turns on the platform’s challenge for every login for the next few days.
4. He looks for member accounts with successful logins from the attacking addresses. Two appear. He signs those accounts out, forces a password reset and emails both members personally.
5. He posts a short notice for all members.

This week our login page was targeted by automated software trying passwords leaked from other websites. Our site was not breached, but a small number of accounts that reused passwords from elsewhere were affected, and we have contacted those members directly. If you use the same password here as on any other site, please change it now. You may see an extra check when you log in for the next few days.

Once the attack fades, Declan sets the challenge back to appearing only after failed attempts, and keeps the new firewall rules.

Your next steps

1. Find out what login rate limiting and lockout options your platform and host provide.
2. Set temporary lockouts that lift automatically, with a reset link to unlock sooner.
3. Require two-factor authentication on every administrator account.
4. Switch on new login alerts and breached-password checks if available.
5. Ask your host about a web application firewall.
6. Draft a member notice now, so you are ready if an attack happens.