1 / 15

Attacks on Authentication

CS 378. Attacks on Authentication. Vitaly Shmatikov. Authentication with Shared Secret. Active attacker. not just eavesdrops, but inserts his own messages. “kiwifruit”. “kiwifruit”. ?. Bob. Alice. Alice and Bob share some secret. How can they identify each other on the network?.

darrellf
Download Presentation

Attacks on Authentication

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. CS 378 Attacks on Authentication Vitaly Shmatikov

  2. Authentication with Shared Secret Active attacker not just eavesdrops, but inserts his own messages “kiwifruit” “kiwifruit” ? Bob Alice 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?

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

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

  5. Lamport’s Hash • Main 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) • For verification, only need the tip of the stalk “kiwifruit” n, y=hashn(“kiwifruit”) n ? Verifies y=hash(x) x=hash(…(hash(“kiwifruit”)) Replace with (n-1, x) Bob Alice n-1 times

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

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

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

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

  10. CS 378 Single Sign-On Systems Vitaly Shmatikov

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

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

  13. Passport: Early Glitches • Flawed 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=victim@hotmail.com&id=&cb=&prefem=attacker@attacker.com • Cross-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. History of Passport • Launched in 1999 • By 2002, Microsoft claimed over 200 million accounts, 3.5 billion authentications each month • Current 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. Liberty Alliance • Open-standard alternative to Passport • Promises compliance with privacy legislation • Long list of Liberty-enabled products • See website http://www.projectliberty.org

More Related