A brute force attack tries candidate secrets until one works. Against an online account, those candidates go to a login service; against a stolen password database, they may be tested without contacting the service. Your response depends on which boundary failed, not just how frightening the alert sounds.［1］［2］

Key Takeaways:

Online guessing and offline cracking have different limits and defenses.

Credential stuffing reuses stolen credentials; password spraying spreads a small set of guesses across accounts.

Unique passwords, stronger authentication, and secure recovery reduce account exposure.

Rate limits protect online verification; password hashing protects stored verifiers.

A failed login does not prove that somebody entered your account.

How does a brute force attack work?

A login system compares evidence supplied by a claimant with evidence associated with an account. An attacker can repeat that interaction using guesses. The goal may be your email, a remote-access account, or an administrator login that opens other systems. Knowing a username helps identify the target, but it does not automatically reveal the secret.

The phrase describes a method rather than one particular tool. An exhaustive search explores possible combinations; a dictionary-based search prioritizes likely words and variations. The practical success of either approach depends on password choice, verification cost, allowed attempts, and any additional factor required after the password.［1］

An alert stating that a password attempt failed describes a rejected check. It does not say whether a later attempt succeeded, whether the password was already stolen, or whether an active session was abused instead. Read the service's activity history through its official website before deciding which incident you have.

The diagram separates requests sent to a live service from guesses evaluated against copied password verifiers. A control on one path should not be credited with protecting the other path. For the broader account and device context, use the privacy protection decision framework.

Why do online and offline attacks need different defenses?

Online password guessing

An online attacker submits candidates to a service that still controls verification. That service can slow requests, limit failed attempts, require another factor, and observe suspicious patterns. NIST treats effective rate limiting as a primary control against online guessing.［2］

The defender should consider both the account and the wider traffic pattern. A single IP address may represent an office or mobile carrier, while an attacker may distribute requests across addresses. Blocking an address can help, but it cannot replace account-aware controls or justify treating every person behind that address as hostile.［1］

Recovery is part of this boundary. A protected main login is weakened if password reset relies on an insecure mailbox, easily guessed answers, or an unprotected support process. Review how somebody could regain access without knowing the original password, not only how the ordinary login looks.

Offline password cracking

An offline attacker has copied stored password verifiers and can evaluate guesses elsewhere. The original site's login rate limit no longer regulates those calculations. Storage design matters: a password hashing scheme deliberately makes each guess costly, and salts stop identical passwords from producing identical stored results across accounts.［2］［3］

A hash is not an encrypted password that the service decrypts for each login. The service derives a result from the supplied candidate and compares it with the stored verifier. A weak password can still be guessed even when it was hashed correctly; hashing changes the cost, not the unpredictability of your choice.

Our password storage explanation separates fast general-purpose hashes, password hashing, and encryption. Do not use an online password-testing website that asks you to submit the real secret: a supposed assessment should not become another disclosure.

How is guessing different from credential stuffing and spraying?

These labels describe different attacker inputs and targeting patterns. They can appear together during an incident, but conflating them makes advice less useful. A password can resist guessing yet fail immediately when the same valid credential was exposed at another service.

Attack pattern	What the attacker starts with	Typical target pattern	Most relevant defense
Brute force	Candidate secrets	Many attempts against a target	Unpredictable password, throttling, stronger authentication
Dictionary attack	Likely words and variations	Prioritized guessing	Avoid predictable patterns and common secrets
Credential stuffing	Stolen account and password pairs	Replay across services	Unique passwords and stronger authentication
Password spraying	A few common passwords	Attempts across many accounts	Reject common passwords and correlate activity

A dictionary attack is a guessing strategy, not proof that a dictionary word will always be broken instantly. Context matters: length, predictability, storage design, and allowed attempts all affect the result. Adding a familiar suffix to a common word does not make its structure unpredictable.

Credential stuffing is different because the attacker already holds candidate pairs from another exposure. The stolen-credential replay guide covers that chain in detail. This article focuses on guessing so that its prevention advice remains tied to the actual mechanism.

Spraying exploits common choices across a population. An account may show only a few failures while the service sees similar failures against many users. That is one reason a provider's system-wide detection and individual account history complement each other rather than replace each other.

Which brute force prevention measures can you apply?

Use a different, unpredictable password for every password-based account. A password manager can generate and retain those secrets without requiring you to memorize every one. Protect the manager itself and your primary email account, since recovery often flows through them; the password manager risk checklist explains that dependency.

Enable the strongest authentication option the service supports. A second factor can prevent a correct password guess from becoming a completed login, but factor types differ in phishing resistance and recovery behavior. Never approve a prompt you did not initiate, and do not read a verification code to somebody claiming to be support.［2］

Keep recovery methods current. Store recovery codes separately from the device or bag whose loss they are supposed to cover. For organizational accounts, use the administrator's approved recovery route rather than trying improvised workarounds that could conflict with access policy.

A VPN account deserves the same credential discipline as other accounts that affect your privacy. Consult the account login protection checklist to review authentication and recovery separately from the network tunnel. A tunnel changes a traffic path; it does not increase the randomness of a password stored at a service.

Do not change every strong password merely because a service blocked an unsuccessful attempt. NIST distinguishes evidence of compromise from arbitrary periodic password changes. Change an exposed, reused, or suspected compromised secret, and investigate the corresponding sessions and recovery settings.［2］

Which controls should services apply?

Services should combine verification throttling, rejection of common or compromised password choices, secure storage, stronger authentication, and monitoring. The controls should also cover alternate login endpoints and password reset. Protecting one form while leaving another unlimited gives the attacker a different route to the same account.［2］

Account lockout has a tradeoff: a hostile person can deliberately trigger it to deny access to the legitimate user. OWASP describes this failure mode and the limits of relying on lockouts alone. Choose controls that reduce guessing while preserving a verified recovery path; do not present a fixed lockout number as universally correct.［1］

CAPTCHA can add friction, but it does not make an exposed password secret again or protect a copied database. IP reputation and device signals are also supporting evidence. Treat them as inputs to risk decisions rather than a guarantee that a login is legitimate.

Useful monitoring distinguishes failed attempts from successful authentication, session creation, and later account changes. Logs should support investigation without containing passwords, recovery codes, or reusable session tokens. Administrators need evidence of the affected boundary, not a collection of additional secrets.

How should you respond to a login alert?

Open the official app or type the service's known address yourself. Avoid the alert's link until you have independently verified the notification. Compare the timestamp, account, device description, and reported action with your own recent activity; a location estimate alone can be misleading.

If all activity is rejected and settings are unchanged, strengthen the password if needed and review additional authentication. If a successful login or unauthorized change appears, follow the provider's compromised-account process, revoke unfamiliar sessions, inspect recovery methods, and replace affected secrets from a trusted device.

When the password was reused, check the other accounts that share it. Prioritize the mailbox and other recovery dependencies, then replace reused secrets with unique ones. Keep records of suspicious activity for the provider or your organization's security team without copying confidential tokens into tickets.

If you cannot establish a trusted session, stop experimenting with unofficial recovery services. Contact the provider through its verified channel. An apparent attack can also be a stale client repeatedly using an old password, so preserve the evidence and let the activity history guide the conclusion.

To see how length and character variety change an attacker's workload, read how long it takes to crack a password.

Summary

Identify whether guesses were sent to a live service or evaluated against stolen verifiers.
Match defenses to the mechanism instead of treating all login alerts as the same incident.
Use unique passwords, stronger authentication, and protected recovery dependencies.
Confirm successful access and setting changes before claiming account compromise.

FAQ

Can a strong password still be guessed?

A strong password can still be a candidate, but unpredictability makes successful guessing harder. Reuse, phishing, malware, and insecure recovery can expose an account without exhaustive guessing, so password strength is only one layer.

Is a dictionary attack the same as brute force?

A dictionary attack is a targeted guessing strategy that prioritizes likely words and variations. Exhaustive brute force searches a broader set of possibilities; both need defenses against repeated verification attempts.

Does blocking one IP address stop the attack?

Blocking one address can reduce traffic from that source, but distributed requests can continue elsewhere. Services also need account-aware rate limits and monitoring that avoids penalizing every legitimate user on a shared network.

Does MFA prevent every account takeover?

MFA can stop a guessed password from completing login, but its effectiveness depends on the factor and recovery design. Phishing, compromised sessions, and unsafe recovery remain separate risks that need their own controls.

Why do offline attacks ignore login limits?

Offline attackers calculate against copied password verifiers on their own systems. The original service cannot throttle those calculations, which is why password hashing cost and password unpredictability matter after a database exposure.

Should you change a password after one failed attempt?

One failed attempt does not prove disclosure or successful access. Review official activity, change weak or reused secrets, and replace a password when there is evidence or reasonable suspicion that it was compromised.

Can a VPN make your password harder to guess?

A VPN does not change the password or the service's stored verifier. Network protection and account authentication address different boundaries, so keep strong credentials and recovery controls even when using a tunnel.

How long does brute force take?

There is no universal duration because password structure, hashing cost, hardware, and online restrictions vary. A precise estimate without those assumptions can create false reassurance rather than a useful security decision.

Sources

OWASP — Blocking Brute Force Attacks — https://community.owasp.org/controls/Blocking_Brute_Force_Attacks
NIST — Digital Identity Guidelines: Authentication and Authenticator Management — https://pages.nist.gov/800-63-4/sp800-63b.html
OWASP — Password Storage Cheat Sheet — https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html

Sources checked 5 October 2026.

Related Articles:

What Is a Brute Force Attack?