1. Password Authentication
CS 259
Password Authentication
J. Mitchell
I’m going to talk about work we’ve been doing on designing a compositional logic for protocol correctness.
This is joint work with John Mitchell and Dusko Pavlovic

2. User Password file kiwifruit exrygbzyf kgnosfix ggjoklbsz …
hash function

3. Basic password authentication
Setup
User chooses password
Hash of password stored in password file
Authentication
User logs into system, supplies password
System computes hash, compares to file
Attacks
Online dictionary attack
Guess passwords and try to log in
Offline dictionary attack
Steal password file, try to find p with hash(p) in file

4. Dictionary Attack – some numbers
Typical password dictionary
1,000,000 entries of common passwords
people's names, common pet names, and ordinary words.
Suppose you generate and analyze 10 guesses per second
This may be reasonable for a web site; offline is much faster
Dictionary attack in at most 100,000 seconds = 28 hours, or 14 hours on average
If passwords were random
Assume six-character password
Upper- and lowercase letters, digits, 32 punctuation characters
689,869,781,056 password combinations.
Exhaustive search requires 1,093 years on average

5. When password is set, salt is chosen randomly
Unix password line
walt:fURfuu4.4hY0U:129:129:Belgers:/home/walt:/bin/csh
Compare
Salt
Input
Key
Constant
Ciphertext
25x DES
Plaintext
When password is set, salt is chosen randomly

6. Advantages of salt Without salt With salt
Same hash functions on all machines
Compute hash of all common strings once
Compare hash file with all known password files
With salt
One password hashed 212 different ways
Precompute hash file?
Need much larger file to cover all common strings
Dictionary attack on known password file
For each salt found in file, try all common strings

7. Web Authentication Server Problems password Browser cookie
Network sniffing
Malicious or weak-security website
Phishing
Common password problem
Pharming – DNS compromise
Malware on client machine
Spyware
Session hijacking, fabricated transactions
next few slides

8. Password Phishing Problem
Bank A
pwdA
pwdA
Fake Site
Here’s a problem that you may be familiar with. A user arrives at an official-looking web site, perhaps due to a fraudulent or mistyped address. The user thinks that they’re at a bank site, but actually they’re giving their password to the fake site.
The password can then be used by the attacker to log in to the real bank as the user. These types of identity theft attacks are called “phishing attacks” and have become very common in recent years.
User cannot reliably identify fake sites
Captured password can be used at target site

9. Common Password Problem
Bank A
high security site
pwdA
pwdB =
pwdA
low security site
Site B
Here’s another related, but different attack. Our user has online accounts at many different sites, and because it is difficult to remember a unique password for every site, she uses the same password at her bank and at her newspaper’s login page.
Maybe the newspaper login page isn’t protected by SSL for performance reasons, or maybe the passwords are stored in the clear on the newspaper server. Perhaps the newspaper is owned by a nefarious villian who wants to sell these passwords to the highest bidder. In any case, the security of the bank site is compromised by the low-security site, because the user has a common password at both sites.
So we have a situation where the security of the user’s password is only as strong as the least secure site where the password is used. Merely beefing up security at the bank’s server won’t help us very much. What we need is a client-side security solution to protect the bank password from being given to the newspaper.
Phishing attack or break-in at site B reveals pwd at A
Server-side solutions will not keep pwd safe
Solution: Strengthen with client-side support

10. Defense: Password Hashing
hash(pwdA, BankA)
Bank A
pwdA
pwdB =
hash(pwdB, SiteB)
Site B
Generate a unique password per site
HMACfido:123(banka.com)  Q7a+0ekEXb
HMACfido:123(siteb.com)  OzX2+ICiqc
Hashed password is not usable at any other site
Protects against password phishing
Protects against common password problem
Here’s how password hashing works. Suppose our user gives the same password to both bank A and site B, either because site B is a phishing site or just a site with lower security than the bank.
Rather than send these passwords directly to the remote server, we instead send a hash of the password and the network name of the site. Technically we need to use a Pseudo Random Function like a HMAC, and I’ve given an example here of what the password fido:123 might look like when hashed with two different domain names.
The security properties of the hash function are such that the site can’t easily recover the original password using only the hashed version. We prevent the password phishing attack from getting a password that can be used at the targeted site, as long as the phishing site has a different domain name from the bank. And we solve the common password problem by ensuring that the user has a different unique password everywhere they go.

11. Defense: SpyBlock

12. Defense: SpyBlock
Authentication agent communicates through browser agent
Authentication agent communicates directly to web site

13. SpyBlock protection password in trusted client environment
better password-based authentication protocols
server support required
trusted environment confirms site transactions

14. Goals for password protocol
Authentication relies on password
User can remember password, use anywhere
No additional client-side certificates, etc.
Protect against attacks
Network does not carry cleartext passwords
Malicious user cannot do offline dictionary attack
Malicious server (as in phishing) does not learn password from communication with honest user

15. Simple approach Send hashed passwords Does this “work”? Good points?
Bad points?
Server
hash(pwd|0)
Browser
hash(pwd|1)

16. “Interlock” password protocols
(Set-up Phase) Password p known to both parties
(Key Exchange Phase)
A  B gx
B  A gy k = gxy or some function of gxy
(Authentication Phase)
A  B mack(p, r) for random r
B  A mack(p, s), enck(s) for random s
A  B enck(r)
[Rivest, Shamir, Bellovin, Merrit, … Pederson, Ellison]

17. “Interlock” password protocols
(Set-up Phase) Password p = p1p2 known to both
(Key Exchange Phase)
A  B gx
B  A gy k = gxy or some function of gxy
(Authentication Phase)
A  B mack(p1, r1), mack(p2, r2) random r
B  A mack(p1, s1), mack(p2, s2), enck(s1) random s
A  B enck(r1)
B  A enck(s2)
A  B enck(r2)
[Rivest, Shamir, Bellovin, Merrit, … Pederson, Ellison]

18. ESP-KE key exchange protocol
Prime p and generators , β known
Generate random a Generate random b
A= a / βP mod p B= b mod p A B
If A=0 Abort
k = Ba mod p k = (A βP)b mod p
Mb=H(0,k,P) Mb
If H(0,k,P) ≠ Mb Abort
Ma = H(1,k,P) Ma
If H(1,k,P) ≠ Ma Abort
[M Scott]

19. SRP protocol (Set-up Phase) Carol chooses password P
Steve chooses s, computes x = H(s, P) and v = gx
(Key Exchange Phase)
C Bob looks up s, v
x = H(s, P) s
A = ga A
B,u B = v + gb, random u
S = (B - gx) (a+ux) S = (Avu)b
M1 = H(A,B,S) M verify M1
verify M M M2 = H(A,M1,S)
Key = H(S) Key = H(S)
[Wu]

20. CMU “Phoolproof” proposal
Eliminates reliance on perfect user behavior
Protects against keyloggers, spyware.
Uses a trusted mobile device to perform mutual authentication with the server
password?

22. “Interlock” password protocol
(Set-up Phase) Password p = p1p2 known to both parties
(Key Exchange Phase)
(1) A  B m1 = nA, gx
(2) B  A m2 = nA, nB, gy k=keygen(nA, nB, gxy, A)
(Authentication Phase)
(3) A  B m3 = nB, hmack(p1, r1), hmack(p2, r2)
(4) B  A m4 = nA, hmack(p1, s1), hmack(p2, s2), enck(s1)
(5) A  B m5 = nB, enck(r1)
(6) B  A m6 = nA, enck(s2)
A  B m7 = nB, enck(r2)
(Secure Session Phase)
B  A m8 = nA, enck(Secret Data)
[Rivest, Shamir, Bellovin, Merrit, … , Ellison]