1. slide 1 Vitaly Shmatikov CS 378 Attacks on Authentication

2. slide 2 Authentication with Shared Secret ? Alice and Bob share some secret. How can they identify each other on the network? What have we learned from the systems we’ve seen? Alice Bob “kiwifruit” Active attacker not just eavesdrops, but inserts his own messages

3. slide 3 Challenge-Response Alice Bob “kiwifruit” Active attacker Fresh, random R R hash(“kiwifruit”,R) uMan-in-the-middle attack on challenge-response Attacker successfully authenticates as Alice by simple replay uThis is an attack on authentication, not secrecy Attacker does not learn the shared secret However, response opens the door to offline dictionary attack

4. slide 4 Encrypted Timestamp Alice Bob KEY Encrypt KEY (time) uRequires synchronized clocks Bob’s clock must be secure, or else attacker will roll it back and reuse an old authentication message from Alice uAttacker can replay within clock skew window

5. slide 5 Replace with (n-1, x) Lamport’s Hash Alice Bob n, y=hash n (“kiwifruit”) x=hash(…(hash(“kiwifruit”)) “kiwifruit ” n n-1 times Verifies y=hash(x) ? uMain idea: “hash stalk” Moving up the stalk (computing the next hash) is easy, moving down the stalk (inverting the hash) is hard n should be large (can only use it for n authentications) uFor verification, only need the tip of the stalk

6. slide 6 hash m (“kiwifruit”) “Small n” Attack Alice Bob n, y=hash n (“kiwifruit”) uMessage from Bob is not authenticated! uAlice should remember current value of n “kiwifruit ” Real n Verifies y=hash(x) Yes! ? Fake, small m x=hash n (“kiwifruit”) Easy to compute hash n (…) if know hash m (…) with m<n

7. slide 7 fresh random R B ; encrypt KEY (R A ) Mutual Authentication Alice Bob KEY uMutual authentication: Bob to Alice and Alice to Bob uBob’s reasoning: I must be talking to Alice because… Person who correctly encrypted R B is someone who knows KEY… Only Alice knows KEY… Alice must have encrypted R B … Because R B is fresh, Alice can only know R B if she received my message KEY “I am Alice”; fresh random R A encrypt KEY (R B )

8. slide 8 Reflection Attack uBob’s reasoning: I must be talking to Alice because… Person who correctly encrypted R B is someone who knows KEY… Only Alice knows KEY… No! Bob himself knows KEY, too! uSecurity often fails because of flawed reasoning fresh random R B ; encrypt KEY (R A ) Bob KEY “I am Alice”; fresh random R A encrypt KEY (R B ) Start new session, replay Bob’s number back at him “I am Alice”; R B fresh random R’ B ; encrypt KEY (R B ) Replay Bob’s own message as response from “Alice”

9. slide 9 Timestamp Reflection Alice Bob KEY “I am Alice”; Encrypt KEY (time) uProblem: same key for Alice and Bob Attacker can get Bob to encrypt using Alice’s key How would you avoid this with symmetric cryptography? uProblem: messages don’t include intended recipient uProblem: Bob doesn’t remember his own messages Encrypt KEY (time+1) Soon thereafter… “I am Alice”; Encrypt KEY (time+1)

10. slide 10 Vitaly Shmatikov CS 378 Single Sign-On Systems

11. slide 11 Authenticate Once, Use Everywhere User uIdea similar to Kerberos uTrusted third party issues identity credentials, user uses them to access services all over the Web Sign on once Receive Web identity Access any network service Stores credit card numbers, personal information.NET Passport Email Messenger Web retailers

12. slide 12  3 encrypted cookies  Email and password?  joe@hotmail.com, “kiwifruit” Identity Management with Passport User Website.NET Passport  Log in  Redirect browser to Passport server Passport user database  Check user against database  Redirect browser back to website Passport manager  Decrypt & verify cookies  Requested page

13. slide 13 Passport: Early Glitches uFlawed password reset procedure Password reset didn’t require previous password Attacker sends modified URL requesting reset, receives email from Passport providing URL to change password –http://register.passport.net/emailpwdreset.srf?lc=1033&em=vic tim@hotmail.com&id=&cb=&prefem=attacker@attacker.com uCross-scripting attack Victim stores credit card info in Microsoft Wallet –Information kept in a cookie for 15 minutes Victim then logs into Hotmail & reads attacker’s email –Malicious email contains HTML. Hotmail’s web interface processes it, calls script on another site and hands over cookie.

14. slide 14 History of Passport uLaunched in 1999 By 2002, Microsoft claimed over 200 million accounts, 3.5 billion authentications each month uCurrent status From Directory of Sites at http://www.passport.net: “We have discontinued our Site Directory…” Monster.com dropped support in October 2004 Ebay dropped support in January 2005 Seems to be fizzling out –Still supported by Microsoft and MSN sites

15. slide 15 Liberty Alliance uOpen-standard alternative to Passport uPromises compliance with privacy legislation uLong list of Liberty-enabled products See website http://www.projectliberty.org