Web Browser Privacy and Security Part I

1. Web BrowserPrivacy and SecurityPart I

2. Today’s Topics • Trusted Paths • Context-Sensitive Certificate Verification (optional paper)

3. Trusted Paths • Trusted paths are used to help users ensure that they are communicating with whom they think they are • Ex. Ctrl-Alt-Del in Windows systems cannot be intercepted • Trusted paths for Web are difficult because • From remote server to browser to user • Trivial to make fake UIs that look legit

4. Example Attack #1

5. Example Attack #1 Is this from eBay? No trusted path, hard to tell

6. Example Attack #2

7. Example Attack #2 Is this from eBay? No trusted path, hard to tell

8. Example Attack #3

9. Example Attack #3 Is this from eBay? No trusted path to real eBay to verify

10. One Idea: Dynamic Security Skins • User remembers one image • Shown in a trusted window • User remembers one password • Ease of use • Sites get hashed password only • Uses Secure Remote Password w/ server • Generated using a shared secret Dhamija and Tygar, The Battle Against Phishing: Dynamic Security Skins, SOUPS 2005

11. How to Show Trusted Path • Static security indicators • Ex. Secure window uses a certain color border • Ex. Secure window uses lock icon • Rejected, too predictable and easy to spoof • Custom security indicator • Ex. One indicator per site • Ex. One indicator per user • Rejected, too much effort • (Also too much to remember)

12. Dynamic Security Skins • In theory, lots of imagesshould make it hard to spoof • Trusted path to password window

13. Dynamic Security Skins • A unique pattern is generated by each web site (visual hash) • Trusted path from password entryto web site

14. Another Idea: Tokens • Two factor authentication • Something you have • Usually cryptographic • SecureID • Smart cards • Random cryptographic tokens • Scratch cards

15. A Third Idea: Mobile Phones • Everyone’s got a mobile phone • Client side certificates • Private keys generated/stored on phone • New key for each phone • Keys linked to domain names • Key generated upon new connection • Bluetooth from phone to PC • Very few server modifications

17. Discussion of Trusted Path • “[O]n each launch of Firefox, paint the Firefox interface with a nonintrusive, randomly generated pattern. Because sites wouldn’t be able to replicate this pattern, users would know when they were viewing [a] spoofed UI” • Other ideas for trusted paths? • Other barriers to adoption?

18. Today’s Topics • Trusted Paths • Context-Sensitive Certificate Verification (optional paper)

19. Certificates • A secure way of binding a public key with an identity • Ex. Amazon sends its certificate via https • Makes it easier to encrypt communications • How to know if this certificate is legitimate? • Certificate is also signed by a well-known certificate authority (CA) • Certificates of these CAs often included in web browser

21. Self-Signed Certificates • Some sites use self-signed certificates • Want to avoid monetary and overhead costs • Often leads to security alerts like below

22. Why Certificate Verification Fails • Browser may not know public key of the CA that issued the server’s certificate • Internal web server (only by members of the organization) (significant annual fee)

23. Why Certificate Verification Fails • Browser may not know public key of the CA that issued the server’s certificate • Internal web server (only by members of the organization) (significant annual fee) • Own CA: public key installed in browser (no verification errors), but large number of users / user owned computers means high maint • Issuer’s or the server’s certificate may be expired

24. Why Certificate Verification Fails • Common name of certificate does not match server’s fully qualified domain name • Mistake, ex. s3.acme.com vs s10.acme.com • Might be attacker using his own identity with a CA generated certificate (difficult)

25. Aside: Phishing Attack Signed certificate from Equifax / Geotrust

26. Why Certificate Verification Fails • Common name of certificate does not match server’s fully qualified domain name • Mistake, ex. s3.acme.com vs s10.acme.com • Might be attacker using his own identity with a CA generated certificate (easy, but expensive) • Might be attacker using a stolen certificate (along with the private key) (difficult) • Or might be self-signed certificate (easy)

27. Why Certificate Verification Fails

28. Why Certificate Verification Fails

29. Discussion

30. Context-Sensitive Certificate Verification • Clarify relationship between user and server’s (non verified) certificate • Not giving the user override mechanisms • Distribute signed certificates of internal servers out of band • Use typically unused certificate fields: • CA’s contact information (field: issuer alternative name) • CA administrator’s name, address, telephone and fax numbers, and work hours.

31. Context Sensitive Certificate Verification

32. If you said you are an internal member…

33. If you said you are an external member…

34. Specific Passwords Warnings • Helps prevent eavesdropping • Allow overriding • Existing version:

35. Specific Passwords Warnings Is this an important account?

36. Specific Passwords Warnings

37. Discussion • Thoughts so far on designs? • Context-sensitive Certificate Verification • Specific Password Warnings

38. User Studies • Computer literate users (CLU) • Evaluate: • Likelihood of successful attack in representative security-sensitive Web apps • Possibility of “foolproofing” browsers, so they can be used securely even by untrained CLUs • Can education about the relevant security principles, attacks, and tools improve the security of how users browse the Web? • Note: This last hypothesis is not covered in this presentation

39. Study’s Design • 17 male participants (Pitt CS seniors) • Two studies: • Unmodified browser (IE) • Modified Mozilla Firebird 0.6.1 with CSCV and SPW • No feedback given between these two studies • (Note: ordering not randomized)

40. Study’s Design • Visit three fictional but realistic sites • Students given password protected accounts • Site1: “maintained by Pitt” • Monitor reward points (do well in exams, etc) • HTTPS + Certificate issued by internal CA • Site2: “e-merchant not affiliated with Pitt” • Spend reward points on books, CDs, etc. • HTTPS + bogus certificate • Site3: “users’ Web email accounts” • HTTP only (no certificate)

41. Study’s Design

42. Study’s Results • Guesses?

43. Study’s Results • With current Web browsers, the mentioned attacks are alarmingly likely to succeed • More often than not, users’ behavior defeats the existing Web security mechanisms. • “um, another of those pop-ups.” • “I always just click yes when I see these pop-ups.”

44. Study’s Results • CSCV blocked MITM attacks against HTTPS-based applications completely • SPW greatly reduced the insecure transmission of passwords in an HTTP-based application • Although untrained, users had little trouble using CSCV and SPW

45. Discussion • Thoughts on results?

46. Discussion • Possible novelty effects • People might change behavior after getting used to new messages • Behavior outside of lab study • People might still not go find person to verify