XLinkedInWhatsApp
Security · 3 min · July 2, 2026

Why You Should Never Reuse Passwords

One lock, one key — and why giving copies to strangers ends badly

TL;DR | An Analogy

Reusing a password is like using one master key for your house, car, and office: one copy stolen anywhere unlocks everything. A breach at any site hands attackers a skeleton key to your entire digital life.

The idea

When a site stores your password and gets breached, attackers harvest that credential and immediately try it on Gmail, GitHub, banks, and everywhere else. This is called credential stuffing. Because most people reuse passwords, conversion rates are high enough that attackers industrialise the process. Password uniqueness is the single control that limits blast radius to exactly one service.

Where it shows up

System-design interviews: asked when discussing auth flows, rate-limiting, and account-takeover mitigations — interviewers want you to name credential stuffing explicitly.

On-call: a sudden spike in failed logins from distributed IPs is almost always a stuffing campaign; recognising this shapes your incident response (block by IP reputation, enforce MFA, force resets).

Real systems: Cloudflare, GitHub, and Google all run leaked-credential checks against breach corpora (e.g. Have I Been Pwned's API) and warn or block users whose passwords appear in dumps.

Read the detailed breakdown

The mechanics of credential stuffing

When a service is breached, the dumped data usually contains email-password pairs — sometimes in plaintext, more often hashed. Weak hashes (MD5, unsalted SHA-1) crack within hours on commodity GPUs. Strong hashes (bcrypt, Argon2 with high work factors) slow this down, but they don't stop it indefinitely.

Attackers assemble combo lists — billions of email:password pairs aggregated across breaches — and feed them into tools like Sentry MBA or Selenium-based bots that test credentials at scale across high-value targets. The operation is fully automated.

Why the maths punish reuse

Suppose you reuse one password across 10 sites. Your exposure equals the probability that none of those 10 sites are ever breached. As breach rates compound over years, that probability approaches zero. The 2019 NCSC/Google study found 1.5 % of reused credentials were already in known breach sets at any moment — a 1-in-67 chance per reused password. Across a lifetime of accounts, your odds of clean exposure collapse.

With unique passwords, a breach at site A leaks credentials valid only at site A. Blast radius: one. Recovery: change one password.

What actually happens to stolen passwords

  1. Dump acquired — via SQL injection, misconfigured S3 bucket, insider theft, or purchased from initial-access brokers.
  2. Hash cracking — run against rainbow tables or GPU rigs (Hashcat at ~10 billion MD5 guesses/second on a older-generation or mid-range hardware).
  3. Combo-list enrichment — merged with other dumps, deduplicated, prioritised by domain value.
  4. Stuffing campaign — bots rotate IPs via residential proxies, throttle requests to evade rate limits, and report successful logins.
  5. Monetisation — working credentials are sold per account, used for fraud, or leveraged for spear-phishing.

The right mitigation stack

  • Unique passwords everywhere — generated by a password manager (Bitwarden, 1Password, KeePassXC), not human-chosen.
  • Long > complex — a 20-character random string defeats cracking regardless of character set; humans reliably produce weak patterns when inventing passwords themselves.
  • MFA as defence-in-depth — password reuse becomes less catastrophic but MFA is not a substitute for uniqueness; MFA fatigue attacks and SIM-swap undermine it.
  • Breach monitoring — services and individuals should query the HIBP API or equivalent; this surfaces exposure early.

Why this is a system problem, not just a user problem

Services own responsibility too: enforce bcrypt/Argon2 with strong parameters, rate-limit and challenge on auth endpoints, integrate breach-corpus checks at registration and login. A user reusing a password is a known, predictable failure mode — building systems that assume unique passwords is architectural naivety.

Gotchas — what trips people up
Credential stuffing tools actively rotate through residential proxy networks to defeat IP-based rate limiting, meaning rate limiting alone is insufficient to stop a stuffing campaign.high
Have I Been Pwned's Pwned Passwords list (used by NCSC and others) showed more than 500 million real-world passwords exposed in breaches as of their public dataset — demonstrating the scale of available combo lists.high
Google research found that 1.5% of credentials scanned against breach datasets matched an active user's current password — meaning a significant fraction of live accounts are immediately vulnerable to stuffing.medium
Remember to click if you earned something new :
← All issuesDone? Spin another →