Password Attacks

Password Attacks — Brute Force, Dictionary & Credential Stuffing (How They Work and How to Stop Them)

Passwords are the most common form of authentication — and that makes them the prime target for attackers. Understanding how password attacks work helps you design better defenses. This article explains the three major classes of password attacks — brute force, dictionary, and credential stuffing — shows real-world impact, signs of compromise, and gives practical, prioritized defenses you can implement today.


What are password attacks?

A password attack is any technique an attacker uses to guess, crack, or reuse passwords to gain unauthorized access to accounts or systems. Attackers choose the method depending on resources, scale, and the target’s weaknesses.


1. Brute Force Attacks — exhaustive guessing

How it works:
A brute force attack tries every possible combination until it finds the correct password. For short or simple passwords, this can succeed quickly. For long, random passwords, brute force becomes computationally infeasible.

Why it works:

  • Weak or short passwords have small search spaces.

  • No rate limiting or delays on login attempts.

  • Offline brute force (when attackers have hashed password dumps) is even faster using GPUs.

Real-world example:
An attacker uses a script to repeatedly attempt logins against a web form or attempts millions of password guesses against a stolen password hash offline.

Signs of a brute force attack:

  • High volume of failed login attempts from one IP or many IPs.

  • Multiple lockouts for different users in short time.

  • Spikes in authentication-related errors.


2. Dictionary Attacks — targeted guessing from a list

How it works:
A dictionary attack uses a curated list of likely passwords — real words, common passwords, and known leak-derived values — rather than testing every possible combination. Lists include “password”, “123456”, names, keyboard patterns, and leaked passwords.

Why it works:

  • Many users choose predictable passwords or slight variations of leaked ones.

  • Dictionaries drastically reduce the number of attempts needed vs pure brute force.

Real-world example:
Attackers test login forms or offline hashes using a list of the most common passwords plus variants (e.g., Password1!, Qwerty123).

Signs of a dictionary attack:

  • Repeated attempts using common password values.

  • A pattern of failed attempts across multiple accounts using the same password candidates.


3. Credential Stuffing — reuse at scale

How it works:
Credential stuffing reuses username/password pairs obtained from data breaches against other websites or services. Attackers automate login attempts at scale, trying stolen credentials across many sites.

Why it works:

  • People reuse passwords across services.

  • Even a small reuse rate yields many compromised accounts when attackers try millions of pairs.

Real-world example:
A breach exposes emails and passwords for Website A. Attackers run those pairs against ecommerce, banking, or corporate login pages — many logins succeed because users reused credentials.

Signs of credential stuffing:

  • Large bursts of login attempts for many different accounts with the same credential set.

  • Successful logins from unusual geolocations or device types for accounts that previously never logged in from there.

  • Unusual activity immediately after a big publicized breach (credential lists go live).


Why these attacks succeed

  • Weak password hygiene and reuse by users.

  • Lack of rate limiting, CAPTCHAs, or bot protections.

  • Poor password storage (fast hash algorithms, no salts).

  • No multi-factor authentication (MFA).

  • Insufficient monitoring and anomaly detection.


Practical defenses — prioritized and actionable

Implement these defenses in order of impact and practicality:

1. Require strong password storage (must do)

  • Use slow, memory-hard hashing: Argon2, bcrypt, or scrypt.

  • Always use a unique, per-password salt.

  • Never store plaintext or reversible encryption of passwords.

2. Enforce multi-factor authentication (MFA) (high impact)

  • Offer and strongly encourage MFA (TOTP apps, hardware keys).

  • Make MFA required for high-value operations and privileged accounts.

3. Rate limiting and progressive delays (essential)

  • Throttle failed login attempts per IP and per account.

  • Implement exponential backoff or progressive delays after failed attempts.

  • Consider temporary lockouts with safe unlock flows.

4. Device and behavior-based anomaly detection (very effective)

  • Detect sudden changes in geolocation, device fingerprint, or IP reputation.

  • Step-up authentication (require MFA or challenge) on anomalous logins.

5. Blocklist and password hygiene (easy to add)

  • Block known-bad passwords and commonly leaked credentials (use password blacklists).

  • Prevent easily guessable passwords (common sequences, repeated chars).

6. Credential stuffing defenses (scale defenses)

  • Use bot mitigation and fingerprinting (rate-limit or block known bad bots).

  • Implement progressive login challenges (CAPTCHA, email/MFA step) when suspicious.

  • Monitor for rapid login attempts using credential lists and block sources.

7. Compromised credentials detection

  • Integrate breach feeds (Have I Been Pwned-like APIs) to check if a user’s email/password was exposed; require password reset if found.

  • Notify users and force password resets for accounts using breached credentials.

8. Passwordless & modern auth (long-term improvement)

  • Support passwordless logins (WebAuthn / FIDO2, magic links with short-lived tokens) to eliminate passwords for critical flows.

9. Secure account recovery and MFA fallback

  • Make account recovery strict: require identity proofing or multiple verification steps.

  • Avoid weak recovery flows (security questions that are guessable).

10. Logging, monitoring & incident response

  • Log authentication attempts with sufficient detail (IP, user-agent, device fingerprint, timestamp).

  • Alert on spikes in failed logins, unusual success patterns, or repeated lockouts.

  • Prepare incident response playbooks for suspected credential stuffing or mass compromise.


Developer & operational best practices

  • Use parameterized queries and safe libs for all auth flows.

  • Limit and monitor endpoints that can be abused (login, password reset, session creation).

  • Do not reveal whether username or password caused failure (generic “invalid credentials” messages).

  • Store only necessary authentication metadata.

  • Regularly rotate API keys and credentials for service accounts.

  • Run password audits (hashed) to find weak or duplicate passwords internally and force resets when found.


User-facing guidance (help users stay safe)

  • Encourage use of password managers for unique, long passwords.

  • Promote MFA for all accounts.

  • Educate users about phishing and social engineering (attackers use these to obtain credentials).

  • Advise regular password changes only when there's suspicion of compromise — otherwise encourage unique passphrases over periodic forced changes that lead to weak reuse.


Detecting an active compromise — signs to watch

  • Successful logins from countries or IPs the user has never used.

  • A sudden flood of password reset requests.

  • Unusual transactions immediately after login.

  • Login sessions that switch IPs mid-session or show impossible travel patterns.

  • User reports of unexpected password reset emails or new device sign-ins.

If compromise is suspected, force password resets, invalidate active sessions, require MFA re-enrollment, and investigate logs for scope of compromise.


Incident response checklist for suspected mass credential attacks

  1. Immediately enable additional throttling and CAPTCHAs at the login endpoint.

  2. Block or challenge suspicious IP ranges and known bad bot signatures.

  3. Force password resets for impacted accounts or those using breached credentials.

  4. Rotate sensitive service credentials if needed.

  5. Notify affected users with clear steps (reset password, enable MFA).

  6. Preserve logs and evidence for forensics.

  7. Review controls and harden where necessary.


Summary

Password attacks remain effective because human behavior and weak defenses persist. The combination of strong password storage, MFA, rate limiting, bot detection, and credential breach monitoring reduces risk dramatically. For product teams, favor removing the reliance on passwords where appropriate (passwordless/FIDO) and make secure, friction-balanced defenses the default.

Always assume credentials will leak someday — design systems so a leaked password does not equal an account takeover. Stay proactive: monitor, alert, and harden continuously.

HOME LEARN COMMUNITY DASHBOARD