Login
Free Trial

How to Prevent Brute Force Attacks on Your Website

captcha.eu

Brute force attacks are one of the most persistent threats to website security. In 2026, they combine stolen credential lists, distributed botnets and AI-optimised guessing, making single-layer defences insufficient. This guide explains how each protection layer works, where it falls short on its own, and how to combine them effectively.

Estimated reading time: 12 minutes

Try CAPTCHA.eu free – no credit card
View all integrations

At a Glance

The threat in 2026

Automated tools test millions of combinations per second across distributed IP ranges; simple IP blocking no longer suffices.

Strongest single measure

MFA. Microsoft data shows it stops 99.9% of account compromises, even when passwords are already known

Why CAPTCHA fits here

Proof-of-work CAPTCHA acts as a built-in computational rate limiter that raises the cost of every login attempt for bots before a password is ever tried

The right approach

Defense in depth: no single layer stops everything. MFA, rate limiting, and CAPTCHA together close the gaps each leaves open individually

What this guide covers

The threat in 2026

Brute force is not a new attack. What has changed is its speed, scale, and sophistication. Modern tools no longer run from a single machine with an obvious IP address. Instead, attackers distribute attempts across thousands of IP addresses simultaneously, rotate through proxy networks, and use AI to prioritise the most likely password candidates first, drawing from billions of credentials leaked in prior data breaches.

According to the Verizon Data Breach Investigations Report, stolen credentials are involved in the majority of web application breaches. Brute force and credential stuffing are the primary methods used to obtain them. For website operators, this means the old mental model (“my users have strong passwords, so we are fine”) no longer holds. Attacks target weak passwords, yes. But they also target password reuse across services, and they can sustain millions of attempts per hour without triggering simple rate limits if the traffic is distributed.

The scale of this is not theoretical. In May 2024, a threat actor known as Menelik registered partner accounts on a Dell customer portal and spent three weeks brute-forcing service tag identifiers at around 5,000 requests per minute. Dell did not detect the activity until the attacker sent an email disclosing the vulnerability. By then, records on approximately 49 million customers had been scraped. The attack required no sophisticated exploit, just sustained, automated volume against an endpoint without adequate rate limiting or bot detection.

The practical implication: protecting a login page, a registration form, a password reset flow, or an API endpoint against brute force requires multiple layers working together. The sections below explain each layer, including where it works, where it breaks down, and what fills the gap.

Types of brute force attacks: what they are and what stops each one

Not all brute force attacks work the same way. Understanding the variant shapes what defence you prioritise.

ATTACK TYPE
HOW IT WORKS
PRIMARY DEFENSE
Simple brute force
Tries every possible character combination in sequence
Long, complex passwords; account lockout
Dictionary attack
Uses lists of common words and known passwords
Strong password policy; block common passwords
Credential stuffing
Replays username/password pairs from data breaches on other sites
MFA; CAPTCHA; breach-password screening
Password spraying
Tries a few common passwords across many accounts to avoid lockout
Rate limiting per username; anomaly detection
Hybrid attack
Combines dictionary words with numbers and symbols
Passphrases; password managers; MFA
Rainbow table attack
Uses precomputed hash tables to reverse password hashes
Salted hashing; modern hash algorithms (bcrypt, Argon2)

Credential stuffing and password spraying deserve special attention because they are the variants that most easily defeat measures designed only for simple brute force. Credential stuffing does not need to guess passwords; it already has them. Password spraying avoids detection by staying under account lockout thresholds. Both require defences beyond password policy alone.

For a deeper look at credential stuffing specifically, see our guide on what credential stuffing is and how it works.

Six prevention layers that work together

  • Multi-factor authentication

    MFA is the single strongest defence against brute force attacks, and the evidence is unambiguous. Microsoft’s analysis of account compromise incidents found that MFA would have prevented 99.9% of them. The reason is structural: even when an attacker correctly guesses or obtains a password, MFA requires a second factor (a TOTP code, a hardware key, or a push notification) that the attacker does not have access to. For website operators, the priority is MFA on every administrator and high-privilege account, followed by MFA on any account with access to sensitive data or financial flows. Enforcing MFA for all end users depends on the audience and risk profile, but modern browser support for passkeys and authenticator apps makes it achievable for most use cases.

  • Rate limiting and progressive delays

    Rate limiting restricts how many login attempts a client can make within a given time window. It is a straightforward and effective first line of defence against unsophisticated attacks. After a defined number of failed attempts from the same IP address, the server introduces a delay, returns a temporary block, or requires an additional verification step. The limitation of simple IP-based rate limiting is that modern distributed attacks route requests through thousands of different IP addresses. Each individual IP stays under the threshold while the total attack volume remains enormous. A more robust approach combines IP-level rate limiting with per-account thresholds, tracking failed attempts per username regardless of originating IP, and pairs that with anomaly detection that flags unusual traffic patterns globally, not just per source.

  • Account lockout policies

    Account lockout temporarily or permanently blocks an account after a set number of failed login attempts. The OWASP Authentication Cheat Sheet recommends a threshold of five to ten failed attempts before a time-based lockout applies. Hard lockouts (where an account is locked until an administrator manually unlocks it) provide the strongest protection but create a risk of denial-of-service abuse. An attacker can deliberately trigger lockouts on many accounts, preventing legitimate users from logging in. Progressive delays are generally preferable: each failed attempt increases the wait time before the next attempt is permitted, frustrating automated tools without permanently blocking real users.

  • Strong password policies

    Password length matters more than complexity. A 16-character passphrase made of random words is harder to crack than an 8-character string of letters, numbers, and symbols. Password managers make long, unique passwords practical across every account. For website operators, the most impactful policy is requiring passwords of at least 12 characters and screening new passwords against known breach databases, rejecting any password that has appeared in prior leaks. Password policy addresses simple brute force and dictionary attacks well. It provides almost no protection against credential stuffing, where the attacker already has the correct password. That is why password policy alone is insufficient as a brute force defence.

  • CAPTCHA as a structural bot barrier

    CAPTCHA works differently from the other layers on this list. Rather than limiting what an attacker can do after a failed attempt, it raises the cost of every attempt before it reaches your authentication logic. That distinction matters. The key distinction is between traditional visual CAPTCHA and modern proof-of-work CAPTCHA. Traditional CAPTCHA (image grids, distorted text) is increasingly breakable. AI-powered tools solve image challenges automatically, and CAPTCHA-solving farms can process millions of challenges per day for a few dollars. Against a determined, resourced attacker, a visual CAPTCHA provides less protection than it appears to. Proof-of-work CAPTCHA operates differently. Instead of asking the user to identify objects in a picture, it requires the browser to perform a small cryptographic computation before the form can be submitted. For a real user, this happens invisibly in the background before they finish filling in the form. For a bot attempting thousands of logins per minute, every single attempt now requires solving a computational puzzle, raising the cost of the attack regardless of how many IPs or devices the attacker uses. OWASP’s Authentication Cheat Sheet notes that CAPTCHA should be viewed as a defense-in-depth control that makes brute force attacks “more time-consuming and expensive.” With proof-of-work specifically, that cost is built into the architecture rather than dependent on puzzle difficulty.

Why CAPTCHA is structurally different from rate limiting

Rate limiting says: “you may only try X times per minute.” CAPTCHA says: “each attempt requires computational work that cannot be automated cheaply.” A rate-limited attacker simply spreads requests across IPs. An attacker facing proof-of-work CAPTCHA must solve a cryptographic puzzle for every single attempt, across every IP, every device, and every bot in the network. The cost scales linearly with volume, making large-scale attacks economically impractical rather than merely inconvenient.

CAPTCHA.eu uses proof-of-work: invisible, cookieless, EU-hosted

CAPTCHA.eu protects login, registration, and password reset flows with invisible proof-of-work verification. No image puzzles. No cookies. All data processed in Austria under EU law. WACA Silver certified by TÜV Austria against WCAG 2.2 AA.

Start free trial
Why European operators switch from reCAPTCHA

  • Monitoring and anomaly detection

    Even with all the above in place, monitoring is what tells you when something has changed. A brute force attack in progress leaves clear traces: a sudden spike in failed login attempts, an unusual distribution of originating IPs, or a high volume of requests to a single endpoint at an abnormal time.

The following patterns in your logs warrant investigation:

  • Multiple failed login attempts against a single account from different IPs (password spraying)
  • High-volume failed attempts from a single IP or IP range (simple brute force)
  • Sudden spikes in authentication requests outside normal traffic hours
  • Increased load on login, password reset, or registration endpoints without a corresponding increase in successful logins
  • Repeated attempts with slightly varied usernames or email formats against the same password

Modern CAPTCHA services provide dashboard visibility into attempt volumes. An unusual spike in CAPTCHA verifications on a login endpoint is a reliable early signal that a brute force attempt is running.

If an attack is already running: immediate steps

Detection is one thing. Response is another. If you identify a brute force attack in progress, the following sequence limits the damage.

  • Temporarily block the most active IPs or IP ranges.

    This is a short-term measure, not a complete solution. Distributed attacks will route around it, but it reduces immediate load and buys time.

  • Enable CAPTCHA on the targeted endpoint if not already active.

    Even deploying it mid-attack raises the cost for bots that continue trying.

  • Tighten rate limiting thresholds immediately.

    Reduce the permitted attempt window and increase delay durations for the duration of the attack.

  • Force a password reset on any accounts that show anomalous activity.

    If specific accounts have had unusually high failed attempt volumes, require re-authentication before the next successful login is permitted.

  • Check for successful logins that preceded or coincide with the attack traffic.

    An attacker who has already succeeded may be inside while the broader attack continues as a distraction.

  • Preserve your logs.

    Raw access logs from the attack window are essential for post-incident analysis and, if relevant, for regulatory reporting under GDPR or NIS2.

Not yet protected? Add CAPTCHA.eu to your login flow today

CAPTCHA.eu integrates in minutes across WordPress, TYPO3, Keycloak, Magento, and custom stacks. Austria-hosted, no cookies, no puzzles for real users.

Start free trial
See all integrations

Why one layer is never enough

Each defence on this list addresses a specific attack vector. None of them addresses all of them.

MFA stops an attacker who already has the correct password from accessing the account, but it does not stop the brute force traffic from hitting your server. Thousands of failed MFA-blocked attempts still generate load, consume resources, and fill your logs.

Rate limiting controls traffic volume, but modern distributed attacks route around IP-level thresholds without slowing down. It works well against unsophisticated attacks, not against resourced adversaries.

CAPTCHA raises the cost of every attempt computationally, but without MFA, a successful CAPTCHA solve still allows a login attempt to proceed. CAPTCHA filters bots, MFA stops compromised credentials.

Account lockout prevents unlimited guessing, but it creates a denial-of-service risk and does not protect against credential stuffing, where the attacker only needs one attempt per account.

The conclusion from OWASP’s guidance, and from the practical architecture of any well-protected login system, is that these layers are designed to complement each other. A login endpoint that combines CAPTCHA, MFA, rate limiting, and anomaly monitoring is genuinely hard to brute-force at scale. Any one of those elements alone leaves gaps that a determined attacker can exploit.

Frequently Asked Questions

What is the most effective way to prevent brute force attacks?

No single measure stops all variants. The most effective approach combines MFA (which stops account compromise even when passwords are known), CAPTCHA (which raises the computational cost of every automated attempt), and rate limiting (which limits attempt volume). Microsoft’s analysis found that MFA alone would have stopped 99.9% of account compromises it studied, making it the highest-priority single measure if you can only implement one.

Does CAPTCHA stop brute force attacks?

Yes, but the type of CAPTCHA matters. Traditional visual CAPTCHA (image grids, distorted text) is increasingly solved by automated tools and CAPTCHA-solving services. Proof-of-work CAPTCHA is more effective because it requires a cryptographic computation for every attempt, raising the cost regardless of the attacker’s image-recognition capability. Neither type replaces MFA, but both meaningfully increase the effort and cost of a large-scale brute force campaign.

What is the difference between brute force and credential stuffing?

Brute force attacks guess passwords without prior knowledge, trying combinations until one works. Credential stuffing uses known username/password pairs from prior data breaches and tests them on other services, exploiting password reuse. Credential stuffing is faster and more targeted. Strong password policy protects well against brute force but offers little protection against credential stuffing, since the attacker already has the correct password. MFA and CAPTCHA address both.

Is rate limiting enough to prevent brute force attacks?

For simple, single-source attacks, rate limiting is effective. Against modern distributed brute force, where requests come from thousands of different IP addresses simultaneously, IP-based rate limiting is insufficient on its own. Per-account thresholds and anomaly detection supplement it. Combined with CAPTCHA and MFA, rate limiting becomes part of a robust layered defence.

How do I know if my website is under a brute force attack?

The clearest signals are: a sudden spike in failed login attempts in your server logs, high request volumes to authentication endpoints, multiple attempts against different accounts from varying IPs (password spraying), or a CAPTCHA dashboard showing an unusual verification spike. Many brute force attacks go undetected for hours or days in sites without active monitoring. Setting up alerts on authentication failure rates is one of the simplest high-value monitoring improvements a site operator can make.

Does CAPTCHA work without cookies or user consent banners?

Traditional CAPTCHA services typically set cookies, which triggers ePrivacy consent requirements. CAPTCHA.eu operates without cookies by architecture, so there is no cookie-related compliance question to resolve, and no consent banner update required for the CAPTCHA layer. It processes all verification data in Austria under EU law. For European website operators who want bot protection without adding to their consent management overhead, the cookieless architecture is a meaningful practical advantage.

What flows should I prioritise for brute force protection?

Login forms are the primary target, but attackers also target password reset flows (which can bypass a locked account), registration forms (fake account creation at scale), and API authentication endpoints. Any endpoint that accepts credentials or grants access tokens is a potential brute force target. Prioritise protection in that order: login, password reset, API endpoints, registration.

Related reading

Recent Posts

en_USEnglish
de_DEGerman fr_FRFrench es_ESSpanish nl_NLDutch it_ITItalian en_USEnglish