Common Password Attacks Explained — and the Defence Against Each One

Password advice makes much more sense once you know what it is defending against. Each attack below has a specific mechanism and, importantly, a specific countermeasure — some belong to you as a user, others to you as the developer building the login system. Here are the seven attacks that account for nearly all password compromises.

1. Brute Force — Trying Everything

The simplest attack: systematically try every possible password. Online, against a live login form, brute force is nearly hopeless if the site does its job — which is why the defences here are server-side:

• Rate limiting / throttling — cap attempts per account and per IP, with increasing delays
• Account lockout or step-up challenges — after repeated failures, require a CAPTCHA or email verification rather than hard-locking (hard lockout invites denial-of-service against users)
• MFA — even a guessed password fails without the second factor

Offline brute force — against stolen hashes — is another matter entirely: billions of guesses per second are possible against fast hashes. There, the defence is password length (see password entropy) and slow hashing on the server.

2. Dictionary Attacks — Trying the Likely Things First

Nobody brute-forces from "aaaaaaaa". Cracking tools start with wordlists — real leaked passwords, dictionary words, names, cricket teams, film stars — and apply mangling rules that mimic human habits:

base word: "cricket"
rules applied automatically:
  Cricket  cricket1  cricket123  Cricket@2025
  cr1cket  Cr!cket   cricket!    CRICKET
→ thousands of variants tested in microseconds

Defence: never base a password on any word or predictable pattern. A randomly generated password or a true diceware passphrase is not in any list.

3. Credential Stuffing — Reuse Is the Sin

The highest-volume attack on the internet today. Attackers take the billions of email/password pairs from past breaches and replay them against other sites with automated tools: login pairs from a breached forum tried against email providers, banks, food-delivery apps, everywhere. No cracking involved — the password is already known; the only question is where else it works.

Defence as a user: a unique password per site — this single habit makes stuffing impossible against you. Defence as a developer: monitor for bursts of failed logins from distributed IPs, check submitted passwords against breach corpora, and offer MFA.

4. Phishing — Asking You for the Password

Why crack a password when the user will type it into your fake page? Phishing mails and SMS ("your account will be suspended", "your parcel is held at customs") link to pixel-perfect copies of real login pages on lookalike domains. Entropy is irrelevant — a 130-bit password typed into a phishing page is 100% compromised.

• Password manager autofill — fills only on the exact saved domain; a lookalike gets nothing (see how password managers work)
• Phishing-resistant MFA — passkeys and hardware keys cryptographically bind the login to the real origin
• Habit — navigate to sensitive sites yourself instead of clicking links in messages

5. Keyloggers — Capturing the Keystrokes

Malware on a compromised device records everything typed, including passwords — strength and uniqueness cannot help once the device itself is hostile. Defences are about the device: keep the OS and browser updated, avoid pirated software and untrusted downloads, and use MFA so that a captured password alone is not enough. Autofill also helps at the margin, since credentials filled by a manager are not typed.

6. Rainbow Tables — Precomputed Hash Reversal

When a site stores unsalted hashes, an attacker does not need to crack each one — they can precompute (or download) a table mapping hashes back to passwords and reverse millions of them instantly:

unsalted:  md5("monkey123") = same hash for every user, every site
           → one table lookup reverses them all

salted:    hash = bcrypt("monkey123" + unique_random_salt)
           → same password, different hash per user
           → precomputed tables are useless

This is a developer-side defence: salting plus a slow hash (bcrypt, scrypt, Argon2) is non-negotiable. Details in bcrypt vs SHA-256.

7. Breached-Password Lists — and How to Respond

Every breach feeds the wordlists used by attacks 2 and 3. Have I Been Pwned (HIBP) aggregates known breaches so you can check exposure — by email address, or by password using a clever k-anonymity API that never sends your actual password. When you discover you are in a breach:

1. Change the password on the breached site immediately.
2. Change it everywhere else the same or similar password was used — this is the step people skip and attackers count on.
3. Make every replacement unique and generated.
4. Enable MFA on the affected account and your email.
5. Watch for targeted phishing — breached email addresses get more of it.

Developers can call the HIBP Pwned Passwords API at registration time and reject passwords that appear in breaches — one of the highest-value, lowest-effort security features you can ship.

One Table to Remember

Attack               Beaten by
brute force (online)  rate limiting + MFA
brute force (offline) length/entropy + slow hashing
dictionary            randomly generated passwords
credential stuffing   unique password per site
phishing              autofill domain match + passkeys
keyloggers            device hygiene + MFA
rainbow tables        salting (developer side)
breach lists          HIBP checks + rotate exposed passwords

Frequently Asked Questions