What is the difference between a brute force attack and a dictionary attack?

A pure brute force attack tries every possible combination of characters in sequence. A dictionary attack uses a pre-built list of common passwords, words, and phrases. Dictionary attacks are much faster because they skip unlikely combinations and focus on patterns that real users actually choose. In practice, most attacks today are hybrid: they use a dictionary as a starting point and then apply rules to generate variations of each word.

How long does a brute force attack take?

It depends entirely on the password length, the character set, the speed of the attack tool, and the defences in place. A 4-character lowercase password can be broken in seconds. An 8-character password using all character types would take years at typical attack speeds. A 12-character random password is considered practically unbreakable by pure brute force. However, if the password is a common word or phrase, a dictionary attack can find it in seconds regardless of length.

Does CAPTCHA stop brute force attacks?

CAPTCHA makes brute force harder but does not stop it entirely. Basic image CAPTCHAs can be solved by automated tools or outsourced to human solvers at low cost. More advanced challenges such as reCAPTCHA v3 or hCaptcha are more effective but still not a complete defence on their own. Use CAPTCHA as one layer in a wider defence that also includes rate limiting, account lockout, and MFA.

What is the OWASP recommendation for brute force prevention?

OWASP recommends a combination of controls from the ASVS 5.0 V2 Authentication requirements: implement account lockout after no more than 100 failed attempts per hour (V2.2.1), require a minimum password length of 8 characters (V2.1.1), check passwords against breach databases such as HaveIBeenPwned (V2.1.7), log all authentication failures (V2.2.6), and offer multi-factor authentication (V2.2.3). Rate limiting the authentication endpoint is covered in V13.2.

June 19, 2026 · 9 min read · By RestingOwl Security Desk

Brute Force Attacks:How They Work and How to Prevent Them

Q: What is a brute force attack?

A brute force attack is when an attacker uses automated software to try many passwords on a login form until it finds one that works. Early versions tried every possible character combination. Modern versions use smarter strategies: wordlists of common passwords, rules to generate variations such as adding numbers at the end, and databases of real passwords from previous breaches. The attack works against applications with weak passwords, no rate limiting, and no account lockout.

Brute ForceAuthenticationSecurityOWASPNode.jsRate Limiting

Quick Answer: A brute force attack is an automated attempt to gain access to an account by trying every possible password until one works. Modern attackers combine brute force with wordlists, pattern rules, and credential lists from past breaches to make the attack faster and more effective. The defences are rate limiting, account lockout, strong password requirements, and multi-factor authentication.

What Is a Brute Force Attack?

A brute force attack is one of the oldest and most straightforward attacks in security. The attacker uses an automated tool to send login requests to an authentication endpoint, cycling through possible passwords until one is accepted. Early brute force tools worked through every character combination in sequence. Modern tools are smarter: they use wordlists of common passwords, rules to generate variations, and breach databases to try known real passwords first.

Brute force attacks are effective against weak passwords and systems with no rate limiting. A four-character password using only lowercase letters has fewer than 500,000 combinations. A modern attack tool running 1,000 attempts per second would exhaust this search space in under 10 minutes. An eight-character password using all character types expands the search space to trillions of combinations, making pure brute force impractical without other optimisations.

What Are the Types of Brute Force Attacks?

Attack Type	How It Works	Best Defence
Simple brute force	Tries every character combination in order. Exhaustive but slow.	Strong password length and complexity requirements
Dictionary attack	Tries words and phrases from a list of common passwords. Much faster than simple brute force.	Block common passwords at registration. Check against HaveIBeenPwned.
Hybrid attack	Combines dictionary words with character substitutions and number appending, for example Password1 or p@ssw0rd.	Password strength scoring with zxcvbn. Reject predictable patterns.
Reverse brute force	Targets many accounts with one common password such as 123456 or password. Avoids per-account lockout.	Global rate limiting across all accounts, not just per account.
Credential stuffing	Uses real username and password pairs from previous breaches. Not guessing, but replaying stolen credentials.	Breach database checks at login. See our credential stuffing guide.

How Is a Brute Force Attack Different From Credential Stuffing?

Brute force attacks guess. Credential stuffing uses real stolen credentials. A brute force attack starts with no knowledge of the password and works through combinations until it finds one that works. Credential stuffing starts with a leaked list of actual username and password pairs and checks whether those same credentials work on a different service.

In practice, attackers often combine both techniques. They might start a campaign with credential stuffing using a large breach database, then fall back to brute force or dictionary attacks against accounts that did not match. The defences overlap: rate limiting, lockout, and MFA protect against both.

Why Do Brute Force Attacks Still Work in 2026?

Weak passwords remain common. Despite years of guidance, users still choose short, predictable passwords. The most common passwords used in breaches are still variations of 123456, password, and qwerty.
Many applications have no rate limiting. Without rate limiting on the login endpoint, an attacker can send thousands of requests per second without any friction.
Account lockout is often missing or too lenient. Many applications either do not lock accounts after repeated failures or set the lockout threshold so high that an attacker can try hundreds of passwords before triggering it.
Internal systems are often unprotected. Admin panels, internal tools, and staging environments are frequently left without brute force protection, assuming they are not visible externally.
Cloud computing makes attacks cheap. An attacker can rent computing power and run a brute force campaign against a target for a few dollars per hour.

How to Prevent Brute Force Attacks: OWASP Checklist

Brute Force Prevention Checklist

1Rate limit your login endpoint. Apply limits per IP address, per account, and globally across the application.
2Implement account lockout or exponential backoff after a set number of failed attempts. OWASP recommends no more than 100 failed attempts per hour per account.
3Require strong passwords at registration. Enforce minimum length of at least 8 characters and check for common patterns using a password strength library such as zxcvbn.
4Check passwords against the HaveIBeenPwned Pwned Passwords API at registration and password change to block known breached passwords.
5Add CAPTCHA or a proof-of-work challenge after a configurable number of consecutive failed login attempts.
6Log all failed login attempts with timestamps, IP addresses, and user agents. Set up alerts for unusual spikes.
7Offer multi-factor authentication to all users. Require it for admin accounts and any account with access to sensitive data.
8Apply the same rate limiting and lockout logic to password reset and account recovery flows, which are frequent targets.

What Is Account Lockout and How Does It Work?

Account lockout is a control that temporarily or permanently disables an account after a set number of failed login attempts. It forces an attacker to slow down or stop entirely, because every failed attempt carries a risk of triggering the lockout. The most common configurations lock an account for a fixed period (such as 15 or 30 minutes) after 5 to 10 failed attempts within a short window.

Account lockout comes with a trade-off: an attacker who knows a valid username can intentionally lock the account and deny service to the real user. To reduce this risk, implement progressive delays (each failed attempt adds a longer wait before the next is accepted) rather than hard lockouts, or require an email confirmation to unlock the account rather than a time-based reset.

What Is Rate Limiting and Why Is It Critical for Authentication?

Rate limiting restricts how many requests a client can make to an endpoint within a time window. Applied to a login endpoint, it prevents an attacker from trying thousands of passwords per second. A limit of 10 login attempts per minute per IP address, combined with a global limit across all accounts, is enough to make most brute force attacks impractical without blocking legitimate users.

Rate limiting alone is not sufficient because sophisticated attackers route requests through many different IP addresses. Combine it with per-account limits so that even if an attacker rotates IP addresses, the account itself is protected. And combine both with account lockout so that repeated failures carry a consequence regardless of where the request comes from.

What Does OWASP Say About Brute Force Prevention?

The OWASP Authentication Cheat Sheet and ASVS 5.0 V2 controls address brute force prevention directly. OWASP recommends implementing lockout after no more than 100 failed attempts per hour per account (V2.2.1), requiring passwords of at least 8 characters (V2.1.1), and checking submitted passwords against breach databases (V2.1.7). OWASP also requires that all authentication failures are logged and that authentication endpoints are rate limited.

Related reading: Brute force and credential stuffing often run together. Read our guide to credential stuffing attacks and prevention to understand how they differ and how to defend against both. To compare session management strategies, see JWT vs Session Tokens: OWASP Security Comparison.