Common Password Attacks & Risks

Brute Force Attacks: The Baseline Threat

A brute force attack systematically tries every possible password combination until one succeeds. Against an online login form, this is usually impractical past a handful of attempts thanks to rate limiting and account lockouts. The real danger is offline brute forcing — an attacker who has stolen a hashed password database can attempt billions of guesses per second on modern GPU hardware, entirely outside any rate limit the original service could ever enforce, since they're testing candidate passwords against their own copy of the hash rather than the live login form.

This is why password length matters more against brute force than almost any other single factor: every additional character multiplies the total search space, directly increasing the time an offline brute-force attempt requires, in a way rate limiting on the live service can never influence one way or another.

Dictionary Attacks: Smarter Than Random Guessing

Rather than trying every possible combination, a dictionary attack tests passwords from a curated list of likely candidates — common passwords, real words, names, and known patterns derived from previous breaches. Because so many real human-chosen passwords cluster around a relatively small set of predictable patterns, a dictionary attack often succeeds far faster than pure brute force against a typical, non-randomly-generated password, despite testing a tiny fraction of the total theoretical search space.

Modern dictionary attacks also apply "mangling rules" — automatically testing common variations of each dictionary word, including capitalization changes, appended digits, and the exact character substitutions (a→@, o→0) that many people mistakenly believe make a password meaningfully harder to guess.

Credential Stuffing: Reusing Breach Data at Scale

Credential stuffing takes username/password pairs leaked from one service's breach and automatically tests them against many other, entirely unrelated services, succeeding wherever a user reused that same combination. This attack requires no cracking or guessing at all — the attacker already has a valid, working password, just for a different service than the one it's now being tried against. It's one of the most consistently damaging attack categories precisely because it converts a single breach into potentially dozens of compromised accounts for any user who reused a password across multiple services.

The defense here isn't password strength at all — a maximally strong, unique password for every account is what actually stops credential stuffing, since a genuinely unique password for each service means a breach at one has zero effect on any other account you hold.

Password Spraying: Low and Slow to Avoid Detection

Password spraying inverts the usual brute-force approach: instead of trying many passwords against one account, an attacker tries one or a handful of extremely common passwords (Password123, Welcome1, the current season and year) against a huge number of different accounts. Because each individual account only receives one or two login attempts, this technique evades the account-lockout mechanisms designed to stop repeated attempts against a single account, while still succeeding against whichever fraction of a large user base happened to choose one of the handful of passwords being sprayed.

Organizations are particularly vulnerable to spraying against corporate login portals, since a large employee base statistically guarantees some fraction will have chosen one of the small set of extremely common passwords the attacker is testing, regardless of how strong the organization's password policy claims to be on paper.

Phishing: Skipping the Password Entirely

Phishing bypasses password strength altogether by tricking the account owner into directly typing their real credentials into a fake but convincing login page, or into revealing a one-time MFA code to an attacker impersonating a legitimate support contact. No amount of password entropy provides any protection here, because the victim is voluntarily providing the actual, correct password — the attack targets human judgment, not the mathematics of the password itself.

Spotting phishing reliably usually comes down to checking the actual destination of a link (not just the display text) before entering credentials, verifying sender domains rather than just display names, and treating any unexpected urgency ("your account will be suspended in 24 hours") as a specific red flag rather than a reason to act quickly. Our IP intelligence guide covers how the suspicious login attempts that follow a successful phishing attack often show up as anomalous geographic or network patterns in server logs.

Keylogging and Credential-Stealing Malware

Keyloggers and dedicated credential-stealing malware capture passwords directly from a compromised device — either by recording every keystroke as it's typed, or by directly reading stored, cached, or autofilled credentials from a browser or password manager's local storage. This attack vector defeats password strength just as thoroughly as phishing does, since it captures the actual password regardless of how random or lengthy it is, by observing it at the moment of entry rather than attempting to guess it.

Defense here shifts away from password practices entirely and toward endpoint security: keeping operating systems and browsers patched, avoiding software from untrusted sources, and using hardware security keys or authenticator apps for MFA rather than SMS codes, since a keylogger capturing a one-time SMS code as it's typed defeats that factor just as easily as it defeats the password itself. A malware infection is also frequently discovered indirectly — through the kind of behavior covered in our malware signatures guide, which explains how scanners actually detect an infection already present on a system.

Rainbow Table Attacks: Precomputation Against Weak Storage

A rainbow table is a precomputed lookup structure mapping common password values to their hash outputs for a specific hashing algorithm, letting an attacker instantly identify a password from its hash without performing any real-time cracking computation. This attack only works against unsalted password hashes — a single unique salt per password, standard practice in any properly built modern system, makes precomputed rainbow tables entirely useless, since the same password now produces a different hash for every single user.

Rainbow table attacks are less of a live threat against well-built modern services today specifically because salting became standard practice years ago, but they remain a real risk against legacy systems, poorly-configured internal tools, or any database where a developer skipped salting under the mistaken belief that hashing alone was sufficient protection.

Social Engineering and Shoulder Surfing

Beyond digital phishing, social engineering covers a broader range of manipulation tactics — a caller impersonating IT support and requesting a password "for verification," a convincing pretext for resetting account recovery details, or simply observing someone type their password in a public space (shoulder surfing). These attacks succeed by exploiting trust, urgency, or simple physical observation rather than any cryptographic weakness, and no password strength or hashing algorithm provides any defense against them at all.

The most reliable defense is procedural: legitimate IT support and service providers never need your actual password to help you, and building institutional awareness of that fact closes off a significant share of successful social engineering attempts before they even require a technical response.

Man-in-the-Middle Interception

A man-in-the-middle attack intercepts communication between you and a legitimate service, capturing credentials as they're transmitted — historically common on unencrypted public Wi-Fi networks, and still a risk wherever a connection lacks proper TLS encryption or where a user is tricked into accepting a fraudulent certificate. Properly implemented HTTPS (covered in depth in our SSL/TLS guide) is specifically designed to prevent this by encrypting the connection and cryptographically verifying the server's identity before any credential is transmitted.

The practical defense: verify a legitimate padlock/HTTPS indicator before entering credentials on any site, avoid entering sensitive credentials over unfamiliar public Wi-Fi where possible, and treat any certificate warning from your browser as a genuine stop signal rather than an obstacle to click through.

Real-World Risk Scenarios

Scenario 1 — The reused-password domino effect: A small, unrelated forum you signed up for years ago suffers a breach. Because you reused that same password for your primary email, an attacker runs credential stuffing and gains access to your email — then uses "forgot password" flows on your banking, shopping, and social accounts, since email access alone often lets an attacker reset most other passwords, regardless of how strong each individual one was.

Scenario 2 — The urgent phishing email: An email claiming to be from your bank warns of suspicious activity and links to a page that looks identical to your bank's real login. You enter your credentials under time pressure. No password strength, however high, would have prevented this specific compromise — only checking the actual link destination before clicking would have.

Scenario 3 — The corporate spraying attempt: A company's employee directory is publicly discoverable, and an attacker sprays "CompanyName2026!" against every employee's corporate login. A handful of employees who chose exactly that pattern — satisfying the company's complexity policy on paper — are compromised, while employees using genuinely unique, randomly generated passwords are unaffected.

Scenario 4 — The public Wi-Fi login: Logging into an account over an unencrypted coffee-shop Wi-Fi network without confirming HTTPS is active exposes the raw credential to anyone else monitoring that same network segment, entirely independent of how strong the password itself is.

How to Recognize You've Been Targeted or Compromised

Warning signs worth taking seriously include: unexpected password-reset emails you didn't request, login notification alerts from unfamiliar locations or devices, being unexpectedly logged out of an active session, and receiving MFA codes you didn't request (a strong signal someone already has your password and is attempting the next step). Any one of these warrants an immediate password change on the affected account and a check of any other services where that same password may have been reused.

Why Attackers Automate Almost All of This

Nearly every attack technique covered in this guide is run at scale through automated tooling rather than a human manually guessing passwords one at a time against a specific target. Credential-stuffing tools can test millions of leaked username/password pairs against a target service within hours; password-spraying scripts rotate through thousands of accounts automatically while pacing requests to stay under detection thresholds; and phishing kits are frequently rented or sold as ready-made packages requiring minimal technical skill to deploy. This automation is precisely why the numbers involved in these attacks look so large — a service reporting "millions of login attempts blocked" isn't describing millions of individual human attackers, but a much smaller number of operators running automated tooling against a large target list.

Understanding this automation matters practically: defenses that specifically disrupt automated tooling — rate limiting, CAPTCHA challenges on suspicious traffic patterns, and IP reputation checks against known malicious ranges (the kind our IP reputation guide covers in depth) — provide real protective value at the service level, complementing the account-level defenses (strong unique passwords, MFA) that protect any individual user regardless of what the service itself does.

Why No Single Defense Covers Every Attack Type

A recurring theme across this guide is that no single practice — not password strength, not MFA, not even a password manager — defends against every attack category covered here. A strong, unique password stops brute force and credential stuffing but does nothing against phishing. MFA stops many phishing and stolen-credential scenarios but can itself be undermined by sophisticated real-time phishing kits that relay a one-time code the moment it's entered. Keeping software patched stops malware-based keylogging but has no bearing on social engineering conducted entirely over a phone call.

This is why security guidance consistently recommends layered defenses rather than a single silver-bullet practice: each layer closes off a different category of attack, and the combination is what actually approaches comprehensive protection, rather than any individual measure taken alone, however diligently applied.

Thinking in terms of layers also changes how you respond after an incident. A compromised account doesn't automatically mean your password was weak — it might mean a service you trusted was breached, a device was infected, or a convincing phishing message caught you on a busy day. Diagnosing which layer actually failed determines whether the right fix is a stronger password, enabling MFA, running a malware scan, or simply being more cautious with unexpected links going forward.

Glossary of Key Terms

• Brute force attack: Systematically testing every possible password combination until one succeeds, most dangerous when performed offline against a stolen hash database.
• Credential stuffing: Testing username/password pairs leaked from one breach against unrelated services, exploiting password reuse.
• Password spraying: Testing a small number of common passwords against a large number of accounts to avoid triggering per-account lockouts.
• Rainbow table: A precomputed lookup table mapping common passwords to hash values, defeated entirely by per-password salting.
• Man-in-the-middle attack: Intercepting communication between a user and a legitimate service to capture credentials in transit.

FAQ