Three methods
- Passwords: what you know
- Token: what you have (for example, a key)
- Biometrics: what you are (physical trait of body, fingerprint, eye scan)
User chooses pass, keep file of username/pass pairs
Attacks
- Social engineering (non-technical solutions, but still effective)
- Trickery ("This is the helpdesk, need your pass for maintenance"), bribery, blackmail, etc.
- Online guessing - try to log in w/ guessed password
- If user wrote down password, read it
- Read/change password file
- "Shoulder surfing" - watch user log in
- Telephones at airports: people watch your calling card #
- Spoofing: attacker impersonates system (log into fake program, looks like real login screen)
Countermeasures
- Education (AOL: "We will never ask for your password" on email inbox)
- Make guessing harder
- Hard-to-guess passwords
- "Velocity control" : limit # of logins per unit time
- Have alarm/alert with too many failed logins
- ATM eats card if 3 failed logins
- Limit on $/day
- Give cryptic error messages ("incorrect username or password")
- Don't let them know if user actually exists by saying "incorrect pass"
- Have same delay for all errors
H(x) is "Hash of x"
In passwd file, store username, H(password)
- On login, compare H(entered pass) with stored hash
- If adversary gets passwd file, not fatal
- BUT, can do offline attack (evades velocity control)
- Dictionary attack (have many prehashed passwords, compare to hashes in file), very effective
- To make dictionary attack more difficult, use a random "salt"
- Value mixed in with hash: H(password + salt), so each user has a "different" hash
- Dictionary must incorporate salt value
- Reduce guessability
- Mix case, require punctuation, letters and numbers, etc.
- Problem: guessability vs. memorability
- If pass hard to guess, hard to memorize... and user will just write it down or not use complex pass
