1 / 75

Do’s and Don’ts of Client Authentication on the Web

Do’s and Don’ts of Client Authentication on the Web. Kevin Fu, Emil Sit, Kendra Smith, Nick Feamster. MIT Laboratory for Computer Science. http://cookies.lcs.mit.edu. Presenters:. Vaibhav Gowadia Cory Calmbacher. Goal.

catrin
Download Presentation

Do’s and Don’ts of Client Authentication on the Web

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. Do’s and Don’ts of Client Authentication on the Web Kevin Fu, Emil Sit, Kendra Smith, Nick Feamster MIT Laboratory for Computer Science http://cookies.lcs.mit.edu Presenters: Vaibhav Gowadia Cory Calmbacher University of South Carolina

  2. Goal Identify common mistakes in web authentication and recommend secure authentication protocol. University of South Carolina

  3. Outline • Security Objectives • Security Requirements • Limitations • Proposed Design • Case Studies • Evaluation University of South Carolina

  4. Security Objectives • Authentication • Confidentiality • Privacy University of South Carolina

  5. What requires authentication? • Clients want to ensure that only authorized people can access and modify personal information that they share with Web sites. • Web sites want to ensure that only authorized users have access to the services and content it provides. University of South Carolina

  6. What requires confidentiality? • Online Brokerages • Auction sites • Banks • Online merchants University of South Carolina

  7. What requires privacy? University of South Carolina

  8. Outline • Security Objectives • Security Requirements • Limitations • Proposed Design • Case Studies • Evaluation University of South Carolina

  9. Security Requirements • Secure Authentication • Granularity • Secure against attacks University of South Carolina

  10. Secure Authentication • Cryptography Proper use of existing cryptographic tools preferred over designing new scheme • Passwords Primary means of authentication today • Authenticators Tokens presented by client to gain access to system University of South Carolina

  11. Use Cryptography Appropriately • Use the appropriate amount of security • Do not be inventive • Do not rely on the secrecy of a protocol • Understand the properties of cryptographic tools • Do not compose security schemes University of South Carolina

  12. Protect Passwords • Limit exposure of passwords • Prohibit guessable password • Reauthenticate before changing passwords University of South Carolina

  13. Handling of Authenticators • Make authenticators unforgeable • Protect authenticators that must be secret • Limit lifetime of authenticators • Bind authenticators to addresses • Avoid using persistent cookies University of South Carolina

  14. Granularity • Fine-grained Useful if specific authorization or accountability of user is required • Coarse-grained University of South Carolina

  15. Fine Grained University of South Carolina

  16. Happy Gilmore University of South Carolina

  17. CLICK University of South Carolina

  18. University of South Carolina

  19. Granularity • Fine-grained Useful if specific authorization or accountability of user is required • Coarse-grained Useful if partial user anonymity is desired University of South Carolina

  20. Coarse Grained University of South Carolina

  21. Attacks • Goal of adversary: Break an authentication scheme faster than by brute force • Types: • Existential forgery Forge authenticator for at least one user • Selective forgery Forge authenticator for any chosen user • Replay attack • Total break Recovery of secret key used to mint authenticators University of South Carolina

  22. Adversaries • Interrogative Adversary • Can query a Web server, but not see traffic • Bases next query on previous query results • Eavesdropping Adversary Can see traffic, but not modify • Active Adversary Can see and modify all traffic University of South Carolina

  23. Outline • Security Objectives • Security Requirements • Limitations • Proposed Design • Case Studies • Evaluation University of South Carolina

  24. Security Model Limitations • Performance Higher security implies lower performance • User Acceptability Non-confrontational • Deployability Use protocols and technologies commonly available University of South Carolina

  25. Deployability • Cannot rely on hardware token systems (such as smart card readers) • Limit reliance on computation • ActiveX • Java • JavaScript • SSL • Cookies! University of South Carolina

  26. Text file stored on client’s hard drive Contains information about visitors to a website (such as username and preferences) Types: Persistent Cookies: Stored on computer indefinitely (unless user deletes) Ephemeral / Temporary Cookie: Stored in browser’s memory and disappears when user closes browser What are Cookies? University of South Carolina

  27. Outline • Security Objectives • Security Requirements • Limitations • Proposed Design • Case Studies • Evaluation University of South Carolina

  28. Web-based Authentication University of South Carolina

  29. 1. Username, Password 2. Authentication Token Web-based Authentication Is <username,password> valid ? Server User Login Procedure University of South Carolina

  30. 3. Request, Auth Token 4. Content Web-based Authentication Is Authenticator valid ? Server User Subsequent Requests University of South Carolina

  31. Features of Authenticator • Personalizable • Stateless verification • Server controls lifetime • Can refer to session info on server University of South Carolina

  32. Cookie Recipe • Ingredients • Expiration Time • Data (Optional: Non-confidential info) • Procedure exp=&data=&digest=MAC(exp= &data=) University of South Carolina

  33. Note • This recipe does not require session identifiers, i.e. #state is O(1) • Maintaining session ID’s is O(n) • Session identifiers requires synchronized, duplicated data between servers University of South Carolina

  34. Cookie Example domain .wsj.com Path /cgi SSL? FALSE Expiration 941452067 Variable name fastlogin Value bitdiddleMaRdw2J1h6Lfc University of South Carolina

  35. Cookie Validation • Authentication: Server recalculates MAC • Revocation mechanism: Not provided University of South Carolina

  36. Security Analysis • Forging Authenticator • Solution: MAC • Cookie hijacking • Solution: SSL • Brute force Key Search • Solution: Key rotation University of South Carolina

  37. Outline • Security Objectives • Security Requirements • Limitations • Proposed Design • Case Studies • Evaluation University of South Carolina

  38. Case Studies University of South Carolina

  39. High School Alumni University of South Carolina

  40. High School Alumni University of South Carolina

  41. High School Alumni • Problem: No cryptographic authentication • Adversary: Interrogative • Break: Universal forgery • Today: Sold to another reunion site University of South Carolina

  42. Instant Shop University of South Carolina

  43. Instant Shop: What’s Inside <form action=commit sale.cgi> <input type=hidden name=item1 value=10> Batteries $10 <input type=hidden name=item2 value=99> Biology textbook $99 <input type=hidden name=item3 value=25> Britney Spears CD $25 <input type=submit> Confirm purchase </form> University of South Carolina

  44. Instant Shop: What’s Inside <form action=commit sale.cgi> <input type=hidden name=item1 value=0> Batteries $10 <input type=hidden name=item2 value=0> Biology textbook $99 <input type=hidden name=item3 value=0> Britney Spears CD $25 <input type=submit> Confirm purchase </form> University of South Carolina

  45. Instant Shop • Problem: Server trusts users not to modify HTML variables • Adversary: Interrogative • Today: Out of business University of South Carolina

  46. Sprint PCS University of South Carolina

  47. Sprint PCS University of South Carolina

  48. Sprint PCS • Problem: Secure content can leak through plaintext channels • Adversary: Eavesdropper • Break: Replay University of South Carolina

  49. Fat Brain University of South Carolina

  50. Fat Brain University of South Carolina

More Related