03 · User Authentication
Basics → password attacks → hashing & salt → cracking → tokens → biometrics → remote authentication
(s.N) = slide number.
User authentication = verifying an identity claimed by or for a system entity; basis of access control and accountability (s.4)
Two steps: identification (give identifier) + verification (bind person to identifier). Not message authentication (integrity of messages) (s.4)
Four means (s.5)
- knows: password, PIN
- possesses: key, token, smartcard
- is: fingerprint, retina (static)
- does: voice, signature (dynamic)
Use alone or combined; all have issues (s.5)
Five attacks: offline dictionary, specific account, popular password, single-user guessing, electronic monitoring (s.7)
Offline dictionary: steal the file, compare hashes with common ones. Fix: protect file, IDS, rapid reissue (s.8)
Specific account → lockout. Popular password (one password, many IDs) → ban common ones, scan IPs (s.9)
Single-user guessing → policy (length, charset, change time). Electronic monitoring → strong encryption (s.10)
Why a salt? hides duplicate passwords, slows offline dictionary attacks, hides reuse across systems (s.13)
UNIX Crypt(3): modified DES, password ≤ 8 chars = 56 bits, 12-bit salt, 11-char output; 'woefully insecure' (s.14)
↪ attacked by → 04 · Cracking & better passwords
Better schemes (s.15)
- MD5: 48-bit salt, 1000 loops, 128-bit hash; vulnerable
- Bcrypt (Blowfish): 128-bit salt, 192-bit hash; most secure
Verify: user id picks row → stored salt + typed password → crypt(3) → compare with stored hash (s.12)
Rainbow table = precomputed hashes for all salts: 1.4 GB cracks 99.9% of alphanumeric Windows passwords in 13.8 s; fails with larger salts (s.16)
Purdue: 3% of 7000 passwords ≤ 3 chars; 14,000 hashed: ~1/4 guessed; 25,000 students: >10% after 1010 guesses (s.17-18)
Shadow file: hashes in a separate, privileged-only file. Still leaks via OS bugs, bad permissions, backups, sniffing (s.19)
Reactive checking: system cracks own file, costly. Proactive: reject weak choice when set; likely best (s.20)
Token = object the user possesses (s.21)
Memory card: stores only, magnetic stripe; needs reader, can be lost; fine for ATM, not for computers (s.22)
Smartcard: own processor, memory, I/O (s.23)
- static (like memory card)
- dynamic (new password every minute)
- challenge-response (hash of random number)
Biometrics: face, fingerprint, hand, retina, iris, signature, voice. Iris = highest cost and accuracy (s.24)
Matching score vs stored template; noise → errors. False match = imposter accepted; false non-match = genuine rejected; threshold t trades them (s.25)
Iris banking system (s.32): PIN or iris (high-value); verification server: decrypt → reconstruct → encode → match against iris DB + CIN
Challenge-response: user sends ID → host sends random r → user returns f(r,h(P)) → host compares (s.26-27)
↪ used by → 05 · Tokens
Client attack → strong passwords, limit attempts. Host attack → hashing, protect DB (s.28-29)
Eavesdropping → diligence, multifactor, revoke. Replay → challenge-response, OTP (s.30-31)
Exam traps (quiz style: one-word fill-in, see Past Exam note)
Q: Hashes kept in a separate file? A: shadow file (s.19)
Q: Random value added before hashing? A: salt; it is stored in clear next to the hash (s.12-13)
Q: Attacker re-sends a captured response? A: replay → challenge-response / OTP (s.31)
Q: False match vs false non-match? A: imposter in vs genuine out (s.25)
Gap: slides name Bloom filters (s.3) and an ATM case study (s.2) but never explain them