460 likes | 638 Views
Web Browser Privacy and Security Part I. Today’s Topics. Trusted Paths Context-Sensitive Certificate Verification (optional paper). Trusted Paths. Trusted paths are used to help users ensure that they are communicating with whom they think they are
E N D
Today’s Topics • Trusted Paths • Context-Sensitive Certificate Verification (optional paper)
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
Example Attack #1 Is this from eBay? No trusted path, hard to tell
Example Attack #2 Is this from eBay? No trusted path, hard to tell
Example Attack #3 Is this from eBay? No trusted path to real eBay to verify
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
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)
Dynamic Security Skins • In theory, lots of imagesshould make it hard to spoof • Trusted path to password window
Dynamic Security Skins • A unique pattern is generated by each web site (visual hash) • Trusted path from password entryto web site
Another Idea: Tokens • Two factor authentication • Something you have • Usually cryptographic • SecureID • Smart cards • Random cryptographic tokens • Scratch cards
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
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?
Today’s Topics • Trusted Paths • Context-Sensitive Certificate Verification (optional paper)
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
Self-Signed Certificates • Some sites use self-signed certificates • Want to avoid monetary and overhead costs • Often leads to security alerts like below
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)
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
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)
Aside: Phishing Attack Signed certificate from Equifax / Geotrust
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)
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.
If you said you are an internal member…
If you said you are an external member…
Specific Passwords Warnings • Helps prevent eavesdropping • Allow overriding • Existing version:
Specific Passwords Warnings Is this an important account?
Discussion • Thoughts so far on designs? • Context-sensitive Certificate Verification • Specific Password Warnings
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
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)
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)
Study’s Results • Guesses?
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.”
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
Discussion • Thoughts on results?
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