A brute-force attack is a trial-and-error technique in which an attacker repeatedly tests passwords, encryption keys, security codes, usernames, or other possible values until one works.
The method is called “brute force” because it does not depend on discovering a sophisticated software vulnerability. Instead, it relies on persistence, automation, computing power, weak credentials, and inadequate limits on repeated attempts.
A basic attack might systematically test every possible password combination. More practical campaigns often begin with common passwords, dictionary words, predictable variations, or information associated with the target.
Brute force is most often discussed in relation to account passwords, but attackers may also target:
- Personal identification numbers
- Password-reset codes
- One-time codes
- API keys
- Encryption keys
- Session tokens
- Hidden files and directories
- Recovery answers
- Device passcodes
- Authentication links
A successful attack can lead to account takeover, data theft, unauthorized transactions, administrative access, malware deployment, or further movement through an organization’s systems.
CISA defines brute force as a trial-and-error method used to crack passwords, credentials, and encryption keys by systematically attempting possible values. CISA’s cybersecurity glossary provides the broader security definition.
How Does a Brute-Force Attack Work?
A typical password-focused brute-force attack follows this pattern:
- The attacker identifies an account or authentication endpoint.
- A collection of possible passwords is prepared.
- Automated software submits login attempts.
- The application accepts or rejects each combination.
- The process continues until a password works or the attack is stopped.
- A successful login creates an authenticated session.
- The attacker uses the account or attempts to gain additional access.
The number of possible combinations depends on the password’s length and available character set.
A short numeric PIN has relatively few combinations. A long, randomly generated password has an enormously larger search space and may be impractical to guess through an online login page.
Attackers rarely begin by testing every theoretical combination. They normally prioritize passwords people are most likely to choose.
That can include:
- Common passwords
- Names
- Dates
- Keyboard patterns
- Dictionary words
- Company names
- Sports teams
- Repeated characters
- Passwords exposed in previous breaches
- Predictable substitutions
- Previously used password patterns
OWASP describes brute force as the submission of predetermined values followed by analysis of the server’s responses. OWASP’s brute-force overview notes that attackers may use complete character combinations, dictionaries, or mutated wordlists depending on the target.
Why Are Brute-Force Attacks Dangerous?
Brute-force attacks take advantage of a basic property of authentication systems: the server must evaluate submitted credentials and indicate whether they are valid.
Without effective limits, that process can become a password-testing service for attackers.
A successful attack may allow someone to:
- Access personal information
- Read private communications
- Steal customer data
- View financial records
- Make unauthorized purchases
- Change account settings
- Reset other passwords
- Access cloud applications
- Download stored files
- Create API tokens
- Add new users
- Modify permissions
- Impersonate the account owner
- Reach internal systems
- Establish persistent access
- Deploy malware or ransomware
The consequences depend on the privileges of the compromised identity. Access to an administrator, email, cloud-management, or remote-access account can be much more damaging than access to a low-value account.
Common Types of Brute-Force Attacks
Simple Brute Force
A simple brute-force attack systematically tests possible character combinations.
The process may begin with short passwords before moving to longer ones. It can try lowercase letters, uppercase letters, numbers, symbols, or combinations of those character groups.
This approach becomes much less practical as password length increases because every additional character expands the number of possibilities.
Simple brute force is most effective against:
- Short passwords
- Numeric PINs
- Small key spaces
- Systems with unlimited attempts
- Weak recovery codes
- Predictable token formats
Dictionary Attack
A dictionary attack tests words and passwords from a prepared list rather than every possible combination.
The list may include:
- Common passwords
- Dictionary words
- Popular names
- Keyboard patterns
- Passwords from previous breaches
- Industry terminology
- Frequently used phrases
Because people often choose memorable passwords, a carefully selected list can be more efficient than testing random strings.
Hybrid Brute-Force Attack
A hybrid attack combines dictionary words with predictable modifications.
For example, an attacker may test variations involving:
- Capitalization
- Numbers
- Years
- Symbols
- Repeated characters
- Common substitutions
- Prefixes and suffixes
The goal is to reproduce the ways users often modify an ordinary word to satisfy password requirements.
A password may technically meet a complexity policy while remaining predictable if it follows a familiar pattern.
Reverse Brute Force
A reverse brute-force attack tests one common password against many usernames.
This technique is commonly called password spraying. It can avoid account lockouts because each username receives only a small number of failed attempts.
Password spraying is particularly dangerous in large organizations where even a small percentage of weak passwords can produce successful access.
Credential Stuffing
Credential stuffing uses username-and-password pairs stolen from another breach.
Unlike conventional brute force, the attacker is not necessarily guessing an unknown password. The objective is to discover whether the victim reused an exposed credential on another service.
Credential stuffing, password spraying, and brute force overlap as automated authentication threats, but they produce different login patterns:
- Brute force: Many passwords against one account
- Password spraying: One password against many accounts
- Credential stuffing: Stolen credential pairs against another service
OWASP uses these distinctions in its Authentication Cheat Sheet, which recommends defense-in-depth controls against automated login attacks.
Password Cracking
Password cracking is often performed offline after attackers obtain password hashes from a compromised database or system.
Instead of sending each guess to the original application, the attacker calculates password hashes locally and compares them with the stolen values.
Offline cracking can be much faster than online guessing because it is not constrained by:
- Network delays
- Account lockouts
- Application rate limits
- CAPTCHA
- Login monitoring
- Server response times
The difficulty depends on the password, hashing algorithm, work factor, and whether a unique salt was used.
Strong password storage cannot make a weak password strong, but modern password-hashing algorithms can make large-scale guessing significantly more expensive.
PIN and Security-Code Brute Force
Attackers may target short numeric values used for:
- Account recovery
- Device unlocking
- Transaction approval
- Email verification
- MFA
- Invitation acceptance
- Passwordless login
Short codes require strict attempt limits, short expiration periods, secure generation, and binding to a particular user or transaction.
A six-digit code has a limited number of possible values. It is not secure if the application permits unrestricted attempts.
Security-Question Brute Force
Recovery questions may have a much smaller answer space than passwords.
Questions involving a birthplace, school, family name, favorite team, or pet may be predictable or discoverable through public information.
Security questions should not be treated as a strong authentication factor. Recovery methods need the same careful protection as the main login system.
Directory and Content Brute Force
Brute force can also refer to systematically guessing hidden files, folders, endpoints, record identifiers, or administrative pages.
An attacker may test common paths to identify:
- Backup files
- Configuration files
- Old application versions
- Administrative panels
- Development endpoints
- Exposed archives
- Unlinked documents
Authorization must still protect a resource even if its location is difficult to guess. A hidden URL is not a substitute for access control.
Online vs. Offline Brute-Force Attacks
An online attack sends guesses to a live application or authentication service.
The defender can observe and restrict the attempts using:
- Rate limiting
- Account lockouts
- MFA
- CAPTCHA
- Device analysis
- Network controls
- Security monitoring
An offline attack occurs after the attacker obtains protected credential data, such as password hashes.
The attacker can test guesses locally without interacting with the original service. The organization may not see the cracking activity.
Offline resistance depends heavily on:
- Password strength
- Proper salting
- The password-hashing algorithm
- The configured work factor
- Protection of the credential database
Passwords should be stored using a modern, slow password-hashing algorithm rather than plain text, reversible encryption, or a fast general-purpose hash.
Brute Force vs. Credential Stuffing
Brute force attempts to discover a password through guessing.
Credential stuffing starts with credentials already stolen from somewhere else.
A unique password may resist credential stuffing because it is not valid on another service. It must also be long and unpredictable enough to resist guessing and offline cracking.
The same defense will not solve every authentication attack. Organizations need unique-password support, breached-password screening, MFA, rate limiting, and secure password storage.
Brute Force vs. Password Spraying
Traditional brute force concentrates many guesses on one account.
Password spraying distributes a small number of guesses across many accounts.
This difference matters because a lockout based only on failures for one account may identify conventional brute force but miss a slow spraying campaign.
Detection should analyze both account-level and organization-wide patterns.
Brute Force vs. Phishing
Brute force attempts to discover credentials through automated guessing.
Phishing attempts to persuade a victim to provide credentials or approve access.
Attackers may combine them. A phishing campaign may reveal account names, while brute force is used against the remaining users. A compromised account may then send convincing internal phishing messages.
Brute Force vs. Social Engineering
Social engineering manipulates people. Brute force repeatedly tests possible values.
An attacker may use personal information obtained through social engineering to create more accurate password guesses. Names, anniversaries, employers, hobbies, and locations may all influence weak passwords.
Long, randomly generated passwords reduce the value of personal information in password guessing.
Warning Signs of a Brute-Force Attack
Security teams may observe:
- Numerous failed logins for one account
- Repeated attempts from one IP address
- Attempts distributed across several IP addresses
- Sequential password attempts
- Login requests arriving at unusual speed
- Repeated failures followed by one success
- Increased account lockouts
- Attempts against inactive accounts
- Login traffic from unexpected countries
- Requests from hosting providers or proxy networks
- One device targeting many accounts
- Unusual authentication API traffic
- Repeated password-reset code submissions
- Attempts against administrative accounts
- Increased CAPTCHA failures
- Login attempts outside normal hours
- A successful login followed by major account changes
- Large numbers of requests to hidden paths
OWASP notes that brute-force activity is often visible in authentication logs and that defenders should pay particular attention when many failures are followed by a successful response. OWASP’s guidance on blocking brute-force attacks discusses recognizing and combining controls against these campaigns.
Users may notice:
- Unexpected account-lockout messages
- Password-reset emails they did not request
- Unfamiliar login notifications
- Repeated MFA prompts
- Unknown devices
- Changed recovery information
- Suspicious transactions
- Messages they did not send
- An inability to sign in
These signs should be investigated through the service’s official website or application.
What Makes a System Vulnerable to Brute Force?
Common weaknesses include:
- Short passwords
- Common passwords
- Default credentials
- Unlimited login attempts
- Missing rate limits
- Weak account-lockout policies
- No MFA
- Predictable usernames
- Username enumeration
- Weak password-reset codes
- Long-lived verification codes
- Weak security questions
- Legacy authentication protocols
- Inconsistent protection across APIs
- Weak password hashing
- Excessive account privileges
- Inadequate logging
- Unmonitored authentication activity
Authentication must be protected across every path, not only the primary web login page.
How Can Organizations Prevent Brute-Force Attacks?
Require Multi-Factor Authentication
MFA prevents a password from serving as the only proof of identity.
Even if an attacker guesses the correct password, access should still require another independent factor.
Strong options include:
- Passkeys
- Hardware security keys
- Platform authenticators
- Authenticator applications
- Device-bound credentials
- Certificate-based authentication
CISA explains that MFA greatly reduces the likelihood of account compromise because possession of a password alone is insufficient. CISA’s MFA guidance recommends layered authentication for sensitive accounts and applications.
Phishing-resistant methods should be preferred for administrators, remote access, email, cloud platforms, and other high-value systems.
Support Passkeys
Passkeys use public-key cryptography rather than reusable passwords.
The service stores a public key, while the private key remains associated with the user’s authenticator. There is no password for an attacker to guess through a login form.
Enrollment, recovery, and fallback processes must remain secure. An attacker should not be able to bypass a passkey by choosing a weaker recovery method.
Use Long, Unique Passwords
Long passwords create a larger search space and make systematic guessing more difficult.
Every account should use a unique password. A password manager can generate and store random credentials without requiring users to memorize each one.
Organizations should:
- Allow long passwords
- Permit password-manager autofill and pasting
- Avoid silent truncation
- Accept a broad range of characters
- Screen known weak passwords
- Avoid unnecessary composition rules
- Support passkeys
CISA recommends strong, unique passwords combined with phishing-resistant MFA. CISA’s strong-password guidance also encourages password-manager use.
Block Common and Breached Passwords
Applications should reject passwords that appear in maintained lists of:
- Common passwords
- Known breached passwords
- Default credentials
- Predictable patterns
- Organization-specific terms
A password can satisfy uppercase, lowercase, number, and symbol requirements while still being easy to guess.
Screening should occur during account creation, password changes, and recovery.
Apply Login Throttling
Login throttling limits how quickly an attacker can test passwords.
Controls may include:
- Maximum attempt thresholds
- Increasing delays
- Temporary restrictions
- Risk-based challenges
- Device verification
- CAPTCHA
- Step-up authentication
OWASP recommends login throttling as a core protection against automated authentication attacks. Its Authentication Cheat Sheet advises associating failed-login counters with the account rather than relying only on an IP address.
Design Account Lockouts Carefully
Account lockout can interrupt repeated guessing, but an overly aggressive policy can create denial-of-service problems.
An attacker may deliberately submit incorrect passwords to lock legitimate users out.
A balanced policy should consider:
- The number of attempts
- The observation period
- The lockout duration
- Progressive delays
- Self-service recovery
- Administrative unlocking
- High-value accounts
- Security notifications
- Existing user sessions
OWASP’s Web Security Testing Guide emphasizes balancing resistance to password guessing with the need to avoid denying legitimate access.
Rate-Limit Multiple Dimensions
IP-based blocking alone is insufficient because attackers can distribute requests across many systems.
Rate limits should evaluate combinations of:
- Account
- IP address
- Network range
- Device
- Browser
- Session
- Authentication endpoint
- Geographic location
- Organization-wide volume
The complete pattern matters more than any single signal.
Use CAPTCHA as an Additional Layer
CAPTCHA may slow automated login attempts but should not be the primary defense.
Attackers may use human-solving services, real browsers, compromised devices, or automation that bypasses weaker challenges.
CAPTCHA works best when triggered by suspicious behavior and combined with MFA, rate limiting, device analysis, and monitoring.
Accessible alternatives should be available.
Prevent Username Enumeration
Login and recovery systems should avoid revealing whether an account exists.
Messages such as “unknown user” can help attackers identify accounts before guessing their passwords.
Responses should be appropriately consistent in:
- Visible wording
- Status codes
- API fields
- Timing
- Recovery behavior
Registration, login, password recovery, and support processes should all be reviewed.
Protect Password-Reset Functions
Attackers may brute-force a recovery code instead of the password.
Reset tokens and codes should be:
- Cryptographically random
- Sufficiently long
- Short-lived
- Single-use
- Bound to one account
- Stored securely
- Invalidated after use
- Protected by rate limits
OWASP’s Forgot Password Cheat Sheet recommends uniform responses, secure tokens, expiration, and protections against excessive automated submissions.
Protect Every Authentication Endpoint
Defenses must cover:
- Website logins
- Mobile APIs
- SSO portals
- VPN gateways
- Administrative interfaces
- Legacy protocols
- Developer tools
- Partner portals
- Recovery systems
- Device activation
- GraphQL authentication
- Customer-support tools
Attackers will choose the least protected route.
GraphQL batching and similar API features should not allow numerous authentication attempts to be hidden inside one network request.
Disable Default Credentials
Products and accounts should not use shared or predictable default passwords.
Temporary credentials should be:
- Unique
- Short-lived
- Delivered securely
- Replaced during activation
- Invalidated after use
Unused accounts should be disabled, and inactive privileged identities should be removed.
Store Passwords Securely
Passwords should never be stored in plain text.
Organizations should use an established password-hashing algorithm with an appropriate work factor and a unique salt for each password.
Secure storage does not prevent online brute force, but it reduces the speed and effectiveness of offline cracking after a database compromise.
Use Least Privilege
A compromised account should have only the access required for its role.
Organizations should:
- Separate routine and administrative accounts
- Limit access to sensitive data
- Restrict cloud permissions
- Review dormant privileges
- Require stronger authentication for administrators
- Reauthenticate before high-impact actions
Least privilege limits the damage caused by a successful password guess.
Can a Web Application Firewall Stop Brute Force?
A web application firewall can identify high request volumes, known malicious networks, and obvious automation.
However, attackers may rotate IP addresses, reduce request speed, imitate normal browsers, or target alternative endpoints.
A WAF is helpful as an additional control, particularly during an active attack, but authentication must still enforce MFA, rate limiting, secure passwords, monitoring, and session protection.
Does CAPTCHA Completely Prevent Brute Force?
No.
CAPTCHA can make automation more expensive, but it can be bypassed or solved. It may also create accessibility and usability problems.
Use it selectively as part of a risk-based defense rather than as proof that a login attempt is legitimate.
Does HTTPS Prevent Brute-Force Attacks?
No.
HTTPS encrypts communication between the client and server. It prevents network observers from easily reading or changing authentication traffic.
It does not prevent an attacker from submitting repeated guesses through an encrypted connection.
How Long Does Brute Force Take?
The time depends on:
- Password length
- Character set
- Password predictability
- Attack speed
- Online rate limits
- Hashing algorithm
- Hardware
- MFA
- Lockout rules
- Whether the attack occurs online or offline
An attacker may discover a common password almost immediately, regardless of its theoretical character space. A long, randomly generated password may remain impractical to guess even with substantial resources.
Password strength should therefore be based on length, uniqueness, and unpredictability—not simply the presence of particular character types.
How Should Brute-Force Protection Be Tested?
Testing must be performed only with explicit authorization.
A security review should examine:
- All login endpoints
- Rate limits
- Account lockouts
- Progressive delays
- MFA enforcement
- Password policies
- Breached-password screening
- Username enumeration
- Recovery codes
- Password-reset tokens
- API batching
- Legacy authentication
- Administrative accounts
- Logging and alerts
- Session handling
Testing should use designated accounts and harmless values. It must be coordinated to avoid disrupting real users or triggering unnecessary incident response.
What Should an Organization Do After Detecting Brute Force?
Contain the Attack
Temporary measures may include:
- Blocking malicious sources
- Tightening rate limits
- Activating additional challenges
- Requiring MFA
- Restricting targeted endpoints
- Disabling unnecessary legacy protocols
- Protecting privileged accounts
- Increasing monitoring
Identify Successful Attempts
Investigators should determine whether failed attempts were followed by successful authentication.
Review:
- Authentication logs
- New sessions
- Device registrations
- MFA changes
- Password changes
- Recovery changes
- Application authorizations
- Data access
- Transactions
- Administrative activity
Revoke Suspicious Access
Organizations should revoke:
- Browser sessions
- Mobile sessions
- Refresh tokens
- Remember-me tokens
- Newly created API keys
- Suspicious application connections
- Unrecognized trusted devices
Changing a password may not automatically terminate every existing session.
Reset Compromised Credentials
Affected users should create strong, unique passwords that do not appear in breach or common-password lists.
If the credential was shared, reused, or embedded in software, every affected location must be identified and updated.
Remove Persistence
Investigators should look for:
- New MFA methods
- Changed recovery information
- Mailbox-forwarding rules
- New administrators
- OAuth authorizations
- API tokens
- Scheduled tasks
- Modified permissions
- New trusted devices
Notify Affected Users
Users should receive clear information about:
- The affected account
- Suspicious activity
- Session revocation
- Required password changes
- MFA enrollment
- Activity they should review
- Official support channels
What Should a User Do After Suspected Brute Force?
If you receive unexpected login alerts or account-lockout messages:
- Open the service through its official website or application.
- Change the password to a long, unique value.
- Sign out all other sessions.
- Enable MFA or a passkey.
- Review recovery information.
- Remove unfamiliar devices.
- Check recent transactions and account activity.
- Remove unknown connected applications.
- Secure the associated email account.
- Contact official support if unauthorized access occurred.
Do not approve an unexpected MFA prompt, even if repeated requests become annoying.
Are Brute-Force Attacks Always Successful?
No.
In theory, repeatedly testing every possibility may eventually discover a value if the attacker has unlimited time and attempts. Real systems can make that process impractical or stop it entirely.
Long random passwords, passkeys, MFA, strict rate limits, secure code generation, modern password hashing, monitoring, and account protection can make brute-force attacks ineffective.
The objective is to ensure that authentication cannot be tested quickly enough for guessing to become a practical route into the account.
