1 / 34

Why are web security decisions hard and what can we do about it?

Panel: Frank Hecker Amir Herzberg Sean Smith George Staikos Kelvin Yiu Moderator: Jason Holt. Why are web security decisions hard and what can we do about it?. Approximate Outline. Part I: Defining the problem Locks, logos and lingo HTTP, HTTPS and redirects Emailed links

wynne-grimes
Download Presentation

Why are web security decisions hard and what can we do about it?

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. Panel: Frank Hecker Amir Herzberg Sean Smith George Staikos Kelvin Yiu Moderator: Jason Holt Why are web security decisionshard and what can we do about it?

  2. Approximate Outline • Part I: Defining the problem • Locks, logos and lingo • HTTP, HTTPS and redirects • Emailed links • Documentation • What's “security”? • Part II: Emerging solutions • Part III: Where should we be going?

  3. The Problem: Locks and Logos

  4. The Problem: Locks and Logos

  5. The Problem: Locks and Logos

  6. The Problem: Redirects

  7. The Problem: Redirects

  8. The Problem: Redirects

  9. The Problem: Redirects

  10. The Problem: Emailed Links

  11. The Problem: Emailed Links

  12. The Problem: Documentation

  13. The Problem: What's “security”?

  14. The Problem? • Users have to make risk management decisions, but: • We don't know what's at risk • We don't know what's being used to protect it • We don't know how big the risks are • We don't know who to ask

  15. http://www.mountain-america.net

  16. http://www.mtnamerica.org

  17. Meaning of Certificates/Identity • Current identity vetting procedures vary widely between CAs • Certificates contents (ie: subject) are unclear in meaning and scope • Stronger assurance guarantees should be applied for high profile targets • High assurance certificates project

  18. Proof of Identity • Going to https://www.example.com/ only proves that you are connected to a site with CN that matches 7777 772e 6578 616d 706c 652e 636f 6d • Maybe this should be the new Location: field! • If certificate verification were bi-directional, proof that the server knows the user gives a stronger indication that the identity is that which was expected • Breaks down if the original server was compromised

  19. Usability... is hard! • Uniform indicators across platforms help users get the right thing with all user-agents • Uniform indicators make phishing easy • When we add UI to the browser (chrome): • We are stuck with it • We confuse users • We help users • We add to information overload

  20. Usability and Content • The interface should make it possible to access all information about the connection • The interface should not force the user to make too many decisions or do too many actions • The content should not be able to manipulate the chrome • Again, breaks the Internet • IN THE CONTENT REGION, ALL BETS ARE OFF

  21. Active Approaches To Security • OCSP – Ability to shut down the bad guys • Similarly should be applied to DNS • Anti-phishing databases • Great success for similar initiatives against SPAM • Should be built into the browser, not an add-on • Live content information in the chrome • Co-ordinated active software updates • What's the problem with all of these things?

  22. Emerging Solutions: TrustBar

  23. Emerging Solutions: TrustBar

  24. Thoughts on Browser UI Security Sean W. Smith Department of Computer Science Dartmouth College Hanover, NH 03755 www.cs.dartmouth.edu/~sws/ April 5, 2006 Vox Clamantis in Deserto

  25. Vindication! • We kept hearing "But that's not a real problem, is it?" • Mozilla: touches too many modules, not a "bug fix" 1. "What's your perspective?" Ye, Smith. "Trusted Paths for Browsers." USENIX Security, 2002. • demonstrated how malicious server content can convincingly simulate server-side SSL signals - IE/Windows, Netscape/Linux... and Geotrust • designed, prototyped, validated countermeasure, in Mozilla - not intruding on displayed content - not requiring user preparation or work • http://www.cs.dartmouth.edu/~pkilab/demos/spoofing/ - demos (obsolete) - code (obsolete) Vox Clamantis in Deserto

  26. SSL Trust Root SSL Trust Root? linklings.com cs.dartmouth.edu ??? Page to upload "it's OK" Dartmouth letters • but how should a browser render this? • and what happens when it gets messier (e.g., attestation) 2. A Trusted Path is Not Enough Consider... • old case of https://palmstore vs. "Modus Media" • newer cases of 3rd party college recommendation letter gathering services. A supporting PKI is conceivable, perhaps Vox Clamantis in Deserto

  27. 3. The Other Side of the Trusted Connection • When is your browser using your private key? • For what purpose? • Who else on your system is using it? Marchesini, Smith, Zhao. "Keyjacking: the Surprising Insecurity of Client-Side SSL." PKI 2003. • Client-side SSL == user approval? • Signed Web forms? • "What you see is not always what you sign" Kain Smith Asokan, Josang, 2002. Related anti-phishing work on "Secure Attention Keys" • TIPPI workshop Phishing and Counter-measures: Understanding the Increasing Problem of Electronic Identity Theft (M. Jakobsson and S.A. Myers, editors). John Wiley. To appear, 2006 Vox Clamantis in Deserto

  28. Wednesday, April 5, 2006 Amir Herzberg Computer Science Department, Bar Ilan University http://AmirHerzberg.com Safe Browsing for Dummies :-) Preventing Spoofing and Phishing by Secure Usability and Cryptography

  29. SSL Certificate Validation • Browsers `trust` list of CAs defined by vendor • Users seldom remove unknown/untrusted CAs • Existing certs: limited validation of identity • Completely determined by CA • Inexpensive, `domain validated` certificates • Fully automated: email challenge-response `check` • Abused already in real attacks against banks • TrustBar response: display `organization` from cert • `Domain validated` do not have organization name • IE7 response: `extended validation` certificates

  30. Extended Validation and Alternatives • Extended validation certificates: • Stronger authentication (actuator/notary ?) • New, more expensive certificates • Again trying to impose (better) global quality • Two (better?) alternatives: • Certificate validation service – user delegate trust (e.g. to Norton, …), not bundle trust with IE • Public-protest-period certificates

  31. Single-Click Logon • Idea: avoid entry of password by user • Cannot steal password if user does not enter it! • Improved usability • Trivial to use: must click site identifier (logo) • User cannot enter, submit password via site!! • Same button as `site identification widget` • Support better authentication by sites • Improved efficiency, security (w/ weak passwords) • Secure and convenient mobility • By proxy, device, paper

  32. Authenticating without SSL? • Efficiency (cf. SSL), content distribution network • Alternative to unprotected login pages... • Authentication of displayed content, e.g. Webmail • Display in secure identification widget (TrustBar) • Trusted, certified `wrapper` (frame, scripts, ... ) • Alternative means to do `secure letterhead`? • For validation of properties: PG13, no malware, ...

  33. Default block mode • Default block mode • Display only rated, signed content • By rating agency • Invoked by clicking on special bookmark • Ratings: • This script/executable does not contain malware • This image does not contain any logo or trademark • This page contains only content owned by Foo.com Inc. • This video is rated PG-13 • Ensure correct ratings by reputation or penalties

More Related