Password Attacks — Concepts

Password Attacks — Quick Reference

Attack	Target	Mechanism	Requires Live System?	Primary Defense
Plaintext Exposure	Credential database	Read stored passwords directly — no cracking needed	No (file access only)	Never store passwords as plaintext; use hashing
Password Spraying	Authentication endpoint	Few passwords × many accounts — stays below lockout threshold	Yes	MFA; common-password blocklist; distributed failure monitoring
Online Brute Force	Authentication endpoint	Systematically tries passwords against live login; one account at a time	Yes	Account lockout policy; rate limiting; MFA
Offline Brute Force	Stolen hash file	Computes hashes locally; compares to stored digests; no system interaction	No (hash file only)	Strong slow hashing (bcrypt/Argon2); salting; MFA

Password Storage — Plaintext vs. Hashed

The single most important design decision in credential storage is whether passwords are hashed before storage. The difference in security outcome is absolute — not a matter of degree.

Attribute	Plaintext Storage	Hashed Storage
What is stored	The password as typed: `Sunflower2019`	Fixed-length digest: `8c6976e5b5410415...`
Reversible?	Yes — it is the password	No — one-way transformation; mathematically infeasible to reverse
Impact of database breach	All credentials immediately usable; no further effort required	Attacker must crack each hash individually — time and compute required
Authentication method	Compare stored password to input	Hash the input; compare digest to stored digest
Exam verdict	Never acceptable; replace the application	Required minimum; use strong algorithms with salting

Key hash property for password storage: pre-image resistance. Given only the hash output, it is computationally infeasible to determine the input. This means stored digests are useless to an attacker without brute forcing — which is why algorithm choice (MD5 vs. bcrypt) matters enormously for offline attack feasibility.

SHA-256 Hash Example — Avalanche Effect

The avalanche effect ensures that even a single character change in the input produces a completely different digest — making it impossible to infer anything about the original password from the hash:

Password	SHA-256 Hash (stored)
123456	8d969eef6ecad3c29a3a629280e686cf0c3f5d5a86aff3ca12020c923adc6c92
1234567	8bb0cf6eb9b17d0f7d22b456f121257dc1254e1f01665370476383ea776df414
password	5e884898da28047151d0e56f8dc6292773603d0d6aabbdd62a11ef721d1542d8
Password	e7cf3ef4f17c3999a94f2c6f612e8a888e5b1026878e4e19398b23bd38ec221a

One character change ("password" → "Password") produces a completely different 256-bit hash. An attacker cannot use the hash to determine the password, its length, or any structural pattern. They can only test candidate passwords forward through the hash function.

Password Spraying — Attack Flow

Prerequisite: Attacker has a list of valid usernames — obtained via LDAP enumeration, email harvesting from company website, or public directory

Step 1 — Select spray password: Choose the single most common password: 123456. If any account uses this password, one attempt will find it

Step 2 — First pass across all accounts: Attempt 123456 against every account in the list. Each account receives exactly one failed attempt — well below any lockout threshold (typically 5–10)

Step 3 — No alerts, no lockouts: The authentication system sees distributed failures across many accounts — not concentrated failures on one account. Standard brute force detection based on per-account failure counts is not triggered

Step 4 — Second pass (if needed): Wait a period, then attempt password across all accounts — still only 2 total attempts per account

Step 5 — Hit: One account using 123456 grants access. The attacker has authenticated with one low-rate attempt — no lockout, no alert

Exam distinction: Spraying = few passwords × many accounts. Traditional brute force = many passwords × one account. Spraying is the lockout-evasion variant

Online vs Offline Brute Force — Decision Tree

Condition	Online Attack Applies	Offline Attack Applies
Attacker can reach the login page	Yes	Not required
Attacker has the hash file	Not required	Yes — required prerequisite
Account lockout is enabled	Severely limits attack	Irrelevant — no login attempts made
Strong hashing algorithm (bcrypt)	No effect	Dramatically slows cracking — primary offline defense
MFA is enabled	Blocks authentication even if password found	Blocks authentication even if hash is cracked
Salting is used	No effect	Prevents rainbow table use; forces per-account cracking

Hashing Algorithm — Impact on Offline Brute Force Speed

Algorithm	GPU Hashes/Second (approx.)	Time to Try 1 Billion Passwords	Security Status
MD5	~50 billion/sec (high-end GPU)	< 1 second	Broken — never use for passwords
NTLM (Windows)	~100 billion/sec	< 1 second	Weak — legacy; avoid where possible
SHA-256	~10 billion/sec	~0.1 seconds	Better, but still fast — use salted with many iterations
bcrypt (cost 12)	~20,000/sec	~14 hours	Good — designed to be slow
Argon2id	~1,000–10,000/sec	Days to months	Best current standard — memory-hard

Speed figures are approximate for a single modern GPU; actual performance varies by hardware and implementation. The orders-of-magnitude difference between MD5 and bcrypt is what matters for exam purposes.

Defense Stack — Password Attacks

Attack	Primary Defense	Secondary Defenses
Plaintext storage	Never store passwords as plaintext — use hashing	Replace the application; migrate to hashed storage; force password reset after migration
Password spraying	MFA — even a correct password alone is insufficient	Blocklist of common passwords at creation time; detect distributed failed login patterns across accounts
Online brute force	Account lockout policy — locks after N consecutive failures	Rate limiting; CAPTCHA; MFA; alerting on concentrated login failures
Offline brute force	Strong, slow hashing algorithm (bcrypt or Argon2)	Salting (prevents rainbow tables); MFA (renders cracked hash useless); protect the hash file with strict access controls