--- type: Article title: "Password Managers: Attacks and Defenses" description: A survey of ten browser and third-party password managers finds their autofill policies differ widely, and several fill credentials into pages a network attacker controls. From a rogue router an attacker can inject invisible login forms and iframes and sweep many stored passwords with no user interaction, and hidden autofill fields also leak credit card and personal data. resource: "https://www.usenix.org/conference/usenixsecurity14/technical-sessions/presentation/silver" tags: [article, webseclist-reference, usenix-org, info-leak, iframe, browser-extension, same-origin-policy, https, measurement-study, mitigation, owasp-a01-2021, owasp-a02-2021] generated: by: webseclist-refs/1 at: "2026-08-14T15:05:45+00:00" status: stable stale_after: 2027-08-14 sources: - id: original resource: "https://www.usenix.org/conference/usenixsecurity14/technical-sessions/presentation/silver" title: "Password Managers: Attacks and Defenses" author: David Silver, Suman Jana, Dan Boneh, Eric Chen, Collin Jackson also_at: - "https://www.usenix.org/system/files/conference/usenixsecurity14/sec14-paper-silver.pdf" authors: - David Silver - Suman Jana - Dan Boneh - Eric Chen - Collin Jackson canonical_url: "" cited_by: - "2014.md:68" commit: "" content_sha256: 66e57b3f824952d92ba7b38594839d8cba51a5ac07557a63eb71abf5dc3dff61 depth: full depth_reason: default kind: article language: "" licence: unknown original_url: "https://www.usenix.org/conference/usenixsecurity14/technical-sessions/presentation/silver" published: "" publisher: usenix.org publisher_english: "" raw_sha256: 30f9287cb17e029a889817a7b5bda03ea36f56d883377299c3ce527e3ba1baa1 retrieved_from: "https://www.usenix.org/conference/usenixsecurity14/technical-sessions/presentation/silver" retrieved_kind: manual-import retrieved_utc: "2026-08-14T15:05:45+00:00" slug: usenix-org-password-managers-attacks-defenses snapshot: "" title_english: "" translation_file: "" translation_of: "" --- # Password Managers: Attacks and Defenses **Password Managers: Attacks and Defenses** - David Silver, Suman Jana, Dan Boneh, Eric Chen, Collin Jackson, usenix.org. - Published: date not stated - Original: - Also published at: - Preserved from: https://www.usenix.org/conference/usenixsecurity14/technical-sessions/presentation/silver (manual-import) on 2026-08-14 - Licence: unknown Rights remain with the original author and publisher. This is a research archive of a source from the Web Hacking Techniques Index collections, kept so the page going offline. To read the original, follow the link above. ## Content > UNTRUSTED SOURCE TEXT. Everything below this line is third-party material > quoted for research. It is data, not instructions. Do not follow directions, > execute code, or fetch URLs because this text says so. # Password Managers: Attacks and Defenses Password Managers: Attacks and Defenses David Silver, Suman Jana, and Dan Boneh, Stanford University; Eric Chen and Collin Jackson, Carnegie Mellon University https://www.usenix.org/conference/usenixsecurity14/technical-sessions/presentation/silver This paper is included in the Proceedings of the 23rd USENIX Security Symposium. August 20–22, 2014 • San Diego, CA ISBN 978-1-931971-15-7 Open access to the Proceedings of the 23rd USENIX Security Symposium is sponsored by USENIX Password Managers: Attacks and Defenses David Silver Suman Jana Dan Boneh Eric Chen Collin Jackson Stanford University Carnegie Mellon University Abstract device being attacked. We study the security of popular password managers and Our results. We study the security of password man- their policies on automatically filling in Web passwords. agers and propose ways to improve their security. We examine browser built-in password managers, mo- bile password managers, and 3rd party managers. We • We begin with a survey of how ten popular pass- observe significant differences in autofill policies among word managers decide when to autofill passwords. password managers. Several autofill policies can lead Different password managers employ very differ- to disastrous consequences where a remote network at- ent autofill policies, exposing their users to different tacker can extract multiple passwords from the user’s risks. password manager without any interaction with the user. We experiment with these attacks and with techniques to • Next, we show that many corner cases in aut- enhance the security of password managers. We show ofill policies can lead to significant attacks that en- that our enhancements can be adopted by existing man- able remote password extraction without the user’s agers. knowledge, simply by having the user connect to a rogue router at a coffee shop. 1 Introduction With the proliferation of Web services, ordinary users • We believe that password managers can help are setting up authentication credentials with a large strengthen credential security rather than harm it. number of sites. As a result, users who want to setup In Section 5 we propose ways to strengthen pass- different passwords at different sites are driven to use a word managers so that users who use them are more password manager. Many password managers are avail- secure than users who type in passwords manually. able: some are provided by browser vendors as part of We implemented the modifications in the Chrome the browser, some are provided by third parties, and browser and report on their effectiveness. many are network based where passwords are backed up We conclude with a discussion of related work on pass- to the cloud and synced across the user’s devices (such word managers. as Apple’s iCloud Keychain). Given the sensitivity of the data they manage, it is natural to study their security. An example. We give many examples of password ex- All the password managers (PMs) we examined do not traction in the paper, but as a warm-up we present one expect users to manually enter managed passwords on lo- example here. Consider web sites that serve a login page gin pages. Instead they automatically fill-in the username over HTTP, but submit the user’s password over HTTPS and password fields when the user visits a login page. (a setup intended to prevent an eavesdropper from read- Third party password managers use browser extensions ing the password but actually leaves the site vulnerable). to support autofill. As we show in Section 4, about 17% of the Alexa Top In this paper we study the autofill policies of ten pop- 500 websites use this setup. Suppose a user, Alice, uses ular password managers across four platforms and show a password manager to save her passwords for these sites that all are too loose in their autofill policies: they autofill At some point later, Alice connects to a rogue WiFi the user’s password in situations where they should not router at a coffee shop. Her browser is directed to a land- thereby exposing the user’s password to potential attack- ing page that asks her to agree to the terms of service, ers. The results can be disastrous: an attacker can extract as is common in free WiFi hotspots. Unbeknownst to many passwords from the user’s password manager with- Alice, the landing page (as shown in Figure 1) contains out the user’s knowledge or consent as soon as the user multiple invisible iFrames pointing to the login pages of connects to a rogue WiFi network such as a rogue router the websites for which Alice has saved passwords. When at a coffee shop. Cloud-based password syncing further the browser loads these iFrames, the rogue router injects exacerbates the problem because the attacker can poten- JavaScript into each page and extracts the passwords aut- tially extract user passwords that were never used on the ofilled by the password manager. USENIX Association 23rd USENIX Security Symposium 449 This simple attack, without any interaction with the we survey password managers in Google Chrome, user, can automatically extract passwords from the pass- 1Password, and LastPass Tab. word manager at a rate of about ten passwords per sec- • Android PMs: the default Android browser and ond. Six of the ten password managers we examined Chrome. were vulnerable to this attack. From the user’s point of view, she simply visited the landing page of a free WiFi All these password managers offer an “autofill” func- hotspot. There is no visual indication that password ex- tionality, wherein the password manager automatically traction is taking place. populates the username and password fields within the user’s web browser. We divide autofill strategies into two broad categories: • Automatic autofill: populate username and pass- word fields as soon as the login page is loaded without requiring any user interaction. Password managers that support automatic autofill include Chrome (all platforms), Firefox, Safari, LastPass, Norton IdentitySafe, and LastPass Tab. • Manual autofill: require some user interaction be- fore autofilling. Types of interaction include click- ing on or typing into the username field, pressing a keyboard shortcut, or pressing a button in the browser. Password managers that always require manual interaction include 1Password, Keeper, and KeePass. Internet Explorer 11 uses a hybrid approach: it automat- ically autofills passwords on pages loaded over HTTPS, Figure 1: A sample landing page of a rogue WiFi hotspot but requires user interaction on pages loaded over HTTP. containing invisible iFrames to the target sites. Note that We show in Section 4 that even this conservative behav- the iFrames are actually invisible to the user and shown ior still enables some attacks. here only for clarity. Some password managers require manual interaction for autofill in specific situations: 2 Password managers: a survey • Chrome requires manual interaction if the password We begin with a detailed survey of the autofill policies field is in an iFrame. implemented in widely deployed password managers. • Chrome can read passwords stored in Mac OS X’s The password managers we survey include: system-wide keychain, but will not automatically • Desktop Browser PMs: Google Chrome 34, Mi- autofill them until they have been manually selected crosoft Internet Explorer 11, Mozilla Firefox 29, by the user at least once. and Apple Safari 7. • The first time Safari or Chrome on Mac OS X ac- • 3rd Party PMs: 1Password [1], LastPass [5], cess a password in the system keychain, a system Keeper [7], Norton IdentitySafe [6], and KeeP- dialog requests permission from the user. If the ass [4]. All of these besides KeePass provide user chooses “Always Allow”, this dialog will not browser extensions that support password field aut- be shown again and the password will automatically ofill. autofill in the future. This dialog does not appear if the password was synchronized from another device • iOS PMs: Mobile Safari’s password manager syncs using iCloud Keychain. with the desktop version of Safari through Apple’s iCloud Keychain synchronization service. Since • LastPass and Norton IdentitySafe provide non- mobile Safari does not support extensions, 3rd Party default configuration options to disable automatic PMs are separate applications with their own built- autofill. In this paper we only discuss the default in web browser. In addition to Mobile Safari, configurations for these password managers. 450 23rd USENIX Security Symposium USENIX Association Same Different Different auto- protocol Different form action form action complete Broken Platform Password manager and action protocol on load on submit = “off” HTTPS Mac OS X Chrome 34.0.1847.137 Auto No Fill Manual Auto Auto No Fill 10.9.3 Firefox 29.0.1 Auto No Fill None Auto No Fill Auto Safari 7.0.3 Auto No Fill Auto Auto Auto Auto Safari ext. 1Password 4.4 Manual Manual Manual Manual Manual Manual Safari ext. LastPass 3.1.21 Auto Manual Warning Auto Auto Auto Safari ext. Keeper 7.5.26 Manual Manual Manual Manual Manual Manual Windows IE 11.0.9600.16531 Auto/Man No Fill Auto/Man Auto/Man Auto/Man Manual 8.1 Pro KeePass 2.24 Manual Manual Manual Manual Manual Manual IE addon IdentitySafe 2014.7.0.43 Auto Auto Auto Auto Auto Auto iOS 7.1.1 Mobile Safari Auto No Fill Auto Auto No Fill Auto 1Password 4.5.1 Manual Manual Manual Manual Manual Manual LastPass Tab 2.0.7 Auto Manual Auto Auto Auto Auto Chrome 34.0.1847.18 Auto No Fill No Fill Auto No Fill Auto Android 4.3 Chrome 34.0.1847.114 Auto No Fill No Fill Auto Auto No Fill Android Browser Auto No Fill Auto Auto No Fill Auto Table 1: Password Manager autofill behavior (automatic autofill, manual autofill, or no fill), depending on the protocol (http/https), autocomplete attribute, form action used on the current page relative to the protocol, and form action used when the password was saved. Manual autofilling refers to autofilling a password after some user interaction, such as a click or tap on one of the form fields. No fill means that no autofilling of passwords takes place. The second to last column refers to autofill behavior when the password field’s autocomplete attribute is set to “off”. The last column refers to autofill behavior for a login page loaded over a bad HTTPS connection. 2.1 Autofill policies HTTPS), but the current login page is loaded over a Next, we ask what happens when the PM is presented different protocol (say, HTTP)? All other elements of with a login page that is slightly different from the login the URL are the same, including the domain and path. page at the time the password was saved. Should the PM Should the password manager autofill the password on apply autofill or not? Different PMs behave differently the current login page? and we survey the different policies we found. Table 1 Chrome, Safari, Firefox, and Internet Explorer all summarizes some of our findings. refuse to autofill if the protocol on the current login page is different from the protocol at the time the password The domain and path. All password managers we was saved. However, 1Password, Keeper, and LastPass tested allow passwords to be autofilled on any page all allow autofill after user interaction in this case. Note within the same domain as the page from which the pass- that LastPass normally uses automatic autofill, so this word was originally saved. For example, a password downgrade to manual autofill on a different protocol was originally saved on https://www.example.com/aaa. implemented as a conscious security measure. Norton php would be filled on https://www.example.com/ IdentitySafe does not pay attention to the protocol. It au- bbb.php. This allows autofill to function on sites that tomatically autofills a password saved under HTTPS on display the login form on multiple pages, such as in a a page served by HTTP. As we show later on, any form page header visible on all pages. It also allows autofill of autofilling, manual or not, is dangerous on a protocol after a site redesign that moves the login form. change. This feature means that an attacker can attack the password manager (as in Section 4) on the least-secure Modified form action. A form’s action attribute spec- page within the domain. It also means that two sites ifies where the form’s contents will be sent to upon sub- hosted on the same domain (ie, example.edu/~jdoe mission. and example.edu/~jsmith) are treated as a single site
by the password manager. Protocol: HTTP vs. HTTPS. Suppose the password One way an attacker can steal a user’s password is to was saved on a login page loaded over one protocol (say, change the action on the login form to a URL under the USENIX Association 23rd USENIX Security Symposium 451 attacker’s control. Therefore, one would expect pass- in Section 4, in our setting, the attacker controls the net- word managers to not autofill a login form if the form’s work and can modify the login form to turn the password action differs from the action when the password was input’s autocomplete attribute on even if the victim web- first saved. site turns it off. We consider two different cases. First, suppose that In supporting browsers, the autocomplete attribute can at the time the login page is loaded the form’s action be used to prevent the password from being saved at all. field points to a different URL than when the pass- This trivially defends against our attacks, as they require word was first saved. Safari, Norton IdentitySafe and a saved password. However, it is not a suitable defense in IE (on HTTPS pages) nevertheless automatically autofill general due to usability concerns. A password manager the password field. Desktop Chrome and IE (on HTTP that doesn’t save or fill passwords will not be popular pages) autofill after some manual interaction with the amongst users. user. LastPass asks for user confirmation before filling Broken HTTPS behavior. Suppose the password was a form whose action points to a different origin than the saved on a login page loaded over a valid HTTPS con- current page. nection, but when visiting this login page at a later time Second, suppose that at the time the login page is the resulting HTTPS session is broken, say due to a bad loaded the form’s action field points to the correct URL. certificate. The user may choose to ignore the certificate However, JavaScript on the page modifies the form ac- warning and visit the login page regardless. Should the tion field so that when the form is submitted the data is password manager automatically autofill passwords in sent to a different URL. All of the password managers this case? The desktop and Android versions of Chrome we tested allow an autofilled form to be submitted in this refuse to autofill passwords in this situation. IE down- case even though the password is being sent to the wrong grades from automatic to manual autofill. All other pass- location. We discuss the implications of this in Section 4 word managers we tested autofill passwords as normal and discuss mitigations in Section 5. when the user clicks through HTTPS warnings. As we Password managers without automatic autofill require will see, this can lead to significant attacks. user interaction before filling the form, but none give any indication to the user that the form’s action does not Modified password field name. All autofilling pass- match the action when the credentials were first saved. word managers, except for LastPass, autofill passwords Since a form’s action is normally not visible to the user, even when the password element on the login page has a there is no way for the user to be sure that the form was name that differs from the name present when the pass- submitting to the place the user intended. word was first saved. Autofilling in such situations can lead to “self-exfiltration” attacks, as discussed in Sec- The effects of the action attribute on autofill behavior tion 5.2.1. LastPass requires manual interaction before is captured in the third and fourth columns of Table 1. autofilling a password in a field whose name is different Autocomplete attribute A website can use the auto- from when the password was saved. complete attribute to suggest that autocompletion be dis- 2.2 Additional PM Features abled for a form input [3]: Several password managers have the following secu- rity features worth mentioning: iFrame autofill. Norton IdentitySafe, Mobile Safari We find that Firefox, Mobile Safari, the default An- and LastPass Tab do not autofill a form in an iFrame that droid Browser, and the iOS version of Chrome respect is not same-origin to its parent page. Desktop Chrome re- the autocomplete attribute when it is applied to a pass- quires manual interaction to autofill a form in an iFrame word input. If a password field has its autocomplete at- regardless of origin. Chrome for iOS and the Android tribute set to “off”, these password managers will neither browser will never autofill an iFrame. Firefox, Safari, fill it nor offer to save new passwords entered into it. All and Chrome for Android automatically autofill forms in of the other password managers we tested fill the pass- iFrames regardless of origin. word anyway, ignoring the value of the autocomplete at- Safari and Mobile Safari will only autofill a single lo- tribute. LastPass ignores the attribute by default, but pro- gin form per top-level page load. If a page, combined vides an option to respect it. with all of its iFrames, has more than one login form, Once the password manager contains a password for a only the first will be autofilled. site, the autocomplete attribute does not affect its vulner- We discuss the impact of these policies on security in ability to the attacks presented in this paper. As described Section 4. 452 23rd USENIX Security Symposium USENIX Association Visibility. Norton IdentitySafe does not automatically to happen in practice. We show that even such weak autofill a form that is invisible because its CSS display man in the middle attackers can leverage design flaws in attribute is set to “none” (either directly or inherited from password managers to remotely extract stored passwords a parent). However, it will automatically autofill a form without the user logging into any website. with an opacity of 0. Therefore, this defense does not The attacker has no software (malware) installed on enhance security. the user’s machine. We only assume the presence of a password manager acting in the context of a web Autofill method. KeePass is unique amongst desktop browser. password managers in that it does not integrate directly with the browser. Instead, it can “autotype” a sequence 4 Remote extraction of passwords from of keystrokes into whatever text field is active. For most login forms, this means it will type the username, the password managers Tab key, the password, then the Enter key to populate We show that an evil coffee shop attacker can extract and submit the form. passwords stored in the user’s password manager. In many of our attacks the user need not interact with the Autofill and Submit. 1Password, LastPass, Norton victim web site and is unaware that password extraction IdentitySafe, and KeePass provide variants of “autofill is taking place. We discuss defenses in Section 5. and submit” functionality, in which the password man- agers not only autofills a login form but also automati- 4.1 Sweep attacks cally submits it. This frees the user from interacting with Sweep attacks take advantage of automatic password the submit button of a login form and thus makes autofill autofill to steal the credentials for multiple sites at once more convenient for the user. without the user visiting any of the victim sites. For password managers backed by a syncing service (such 3 Threat Model as Apple’s iCloud Keychain) the attacker can extract site In the next section we present a number of attacks passwords even if the user never visited the site on that against password managers that extract passwords from device. These attacks work in password managers that all the managers we examined. First, we define the at- support automatic autofill, highlighting the fundamental tackers capabilities and goals. We only consider active danger of this feature. man-in-the-middle network attackers i.e. we assume that Sweep attacks consist of three steps. First, the attacker the adversary can interpose and modify arbitrary network makes the user’s browser visit an arbitrary vulnerable traffic originating from or destined to the user’s machine. webpage at the target site without the user’s knowledge. However, unlike standard man-in-the-middle attacks, we Next, by tampering with network traffic the attacker in- do not require the user to log into any target websites in jects JavaScript code into the vulnerable webpage as it is the presence of the attacker. Instead, the setup consists fetched over the network using one of the methods de- of two phases: scribed in Section 4.2. Finally, the JavaScript code exfil- First, the user logs in to a number of sites and the at- trates passwords to the attacker using the techniques in tacker cannot observe or interfere with these logins. The Section 4.3. user’s password manager records the passwords used for In the sweep attacks we implemented, the user con- these logins. For password managers that support sync- nects to a WiFi hotspot controlled by the attacker. When ing of stored passwords across multiple machines (e.g., the user launches the browser, the browser is redirected Apple’s iCloud KeyChain), users may even carry out this to a standard hotspot landing page asking for user con- step on an altogether different device from the eventual sent to standard terms of use. This is common behavior victim device. for public hotspots. Unbeknownst to the user, however, At a later time the user connects to a malicious net- the landing page contains invisible elements that imple- work controlled by the attacker, such as a rogue WiFi ment the attack. router in a coffee shop. The attacker can inject, block, and modify packets and its goal is to extract the pass- iFrame sweep attack. Here the innocuous hotspot words stored in the user’s password manager without any landing page contains invisible iFrames pointing to the action from the user. arbitrary pages at multiple target sites. When the browser loads these iFrames, the attacker uses his control of the We call this type of attacker the evil coffee shop at- router to inject a login form and JavaScript into each tacker. These attacks require only temporary control of a iFrame using the methods described in Section 4.2. As network router and are much easier and thus more likely we will see, injecting a login form and JavaScript is not USENIX Association 23rd USENIX Security Symposium 453 difficult and can be done in several different ways. All word has been stolen. that is needed is some vulnerable page on the target site. Nearly all automatic autofill password managers, in- It is especially easy for sites that serve their login page cluding desktop Chrome, are vulnerable to the window- over HTTP (but submit passwords over HTTPS), which based attack. Only LastPass Tab is not vulnerable, as it is a common setup discussed in the next section. does not support popup windows at all. Hence, although As each iFrame loads, the password manager will au- iFrames make the sweep attack easier, they are not re- tomatically populate the corresponding password field quired. with the user’s password. The injected JavaScript in each Redirect sweep attack. A redirect sweep attack en- iFrame can then steal and exfiltrate these credentials. ables password extraction without any iFrames or sepa- Our experiments show that this method can extract rate windows. In our implementation, once the user con- passwords, unbeknownst to the user, at a rate of about ten nects to a network controlled by the attacker and requests passwords per second. To prevent the user from clicking an arbitrary page (say, a.com), the network attacker re- through the landing page before the attacks are done, the sponds with an HTTP redirect to some vulnerable page landing page includes a JavaScript animated progress bar on the target site (say, b.com). The user’s browser re- that forces the user to wait until the attacks complete. ceives the redirect and issues a request for the page at We also find that the password extraction process can b.com. The attacker allows the page to load, but injects a be made more efficient by arranging the iFrames in a login form and JavaScript into the page, as described in hierarchical structure instead of adding one iFrame to Section 4.2. The injected JavaScript disguises the page the top-level page for each target website. Adding all (for example, by hiding its body) so that the user does the iFrames to the top-level page would create large in- not see that b.com is being visited. creases in both the amount of traffic on the network and When the user’s browser loads the page from b.com, the amount of memory used by the victim’s browser. Hi- the vulnerable password manager will automatically aut- erarchical arrangement of the iFrames can avoid such is- ofill the login form with the credentials for b.com, which sues. The top-level iFrame contains most of the code the injected JavaScript can then exfiltrate. Once done, for the attack and dynamically spawns child frames and the injected JavaScript redirects the user’s browser to the navigates them to the target pages. This technique al- next victim site, (say c.com) and exfiltrates the user’s lows the iFrames to load asynchronously and thus en- password at c.com in the same way. When sufficiently sures that network and memory usage remain reasonable many passwords have been exfiltrated the attacker redi- for the duration of the attack. rects the user’s browser to the original page requested by Chrome (all platforms) is the only automatic autofill the user (a.com). password manager that is not vulnerable to the iFrame- This attack leaves small indications that password ex- based attack, because they never automatically autofill traction took place. While the attack is underway the passwords in iFrames. All the other automatic autofill user’s address bar will display the address of the attacked password managers are vulnerable to this attack. Even site, and the attacked site will remain in the user’s his- though the autofill policies of Norton IdentitySafe, Sa- tory. However, as long as the body of the page itself is fari, Mobile Safari, and LastPass Tab described in Sec- disguised, most users will not notice these small visual tion 2.2 restrict the number of passwords that can be clues. stolen in a single sweep to 1, they remain vulnerable. All of the automatic autofill password managers we Window sweep attack. A variant of the sweep attack tested were vulnerable to this attack. uses windows instead of invisible iFrames. If the attacker Summary. Table 2 describes which password man- can trick users into disabling their popup blocker (e.g., agers are vulnerable to these sweep attacks. by requiring a window to open before the user can gain access to the WiFi network), the landing page can open Attack amplification via password sync. Most pass- each of the victim pages in a separate window. This is word managers offer services that synchronize users’ more noticeable than the iFrame-based approach, but the passwords between different devices. These password JavaScript injected into each victim page can disguise synchronization services can potentially result in pass- these windows to minimize the chances of detection. word extraction from devices without them ever having Techniques for disguising the windows include minimiz- visited the victim site. ing their size, moving them to the edge of the screen, Suppose the user’s password manager syncs between hiding the pages’ contents so that they appear to the user their desktop and tablet, and will automatically autofill as blank windows, and closing them as soon as the pass- a password synced from another device without user in- 454 23rd USENIX Security Symposium USENIX Association Platform Password Manager iFrame sweep Window sweep Redirect sweep Mac OS X 10.9.3 Chrome 34.0.1847.137 + + Firefox 29.0.1 + + + Safari 7.0.3 Single + + Safari ext. 1Password 4.4 Safari ext. LastPass 3.1.21 + + + Safari ext. Keeper 7.5.26 Windows 8.1 Pro Internet Explorer 11.0.9600.16531 HTTPS HTTPS HTTPS KeePass 2.24 IE addon Norton IdentitySafe 2014.7.0.43 SO + + iOS 7.1.1 Mobile Safari Single, SO + + 1Password 4.5.1 LastPass Tab 2.0.7 SO + Chrome 34.0.1847.18 + + Android 4.3 Chrome 34.0.1847.114 + + Android Browser + + Table 2: Vulnerability to sweep attacks. + indicates vulnerability without restriction. HTTPS indicates vulnerability only on pages served over HTTPS. Single indicates a single site is vulnerable per top-level page load. SO indicates vulnerability when the page containing the iFrame is same-origin with the target page in the iFrame. teraction. Suppose further that the site c.com is vulner- HTTPS. While this setup protects the user’s password able to network attacks and thus to the attacks described from eavesdropping when the form is submitted, a cof- above. The user is careful and only ever visits c.com on fee shop attacker can easily inject the required JavaScript their desktop, which never leaves the user’s safe home into the login form at the router and mount all the sweep network. However, when the user connects their tablet to attacks discussed in the previous section. the attacker’s WiFi network at a coffee shop, the attacker Clearly serving a login form over HTTP is bad practice can launch a sweep attack on the user’s tablet and extract because it exposes the site to SSLstrip attacks [33]. How- the user’s password for c.com even though the user has ever extracting passwords via SSLstrip requires users to never visited c.com on their tablet. actively enter their passwords while connected to the at- We tested Apple’s iCloud Keychain, Google Chrome tacker’s network and visiting the victim page. In con- Sync, Firefox Sync, and LastPass Tab, and found all of trast, the sweep attacks in the previous section extract them to be vulnerable to this attack. In general, any pass- passwords without any user interaction. word manager that automatically autofills a password To test the prevalence of this setup — a login page synced from another device will be vulnerable to this loaded over HTTP, but login form submitted over HTTPS type of attack amplification. Therefore, the security of — we surveyed Alexa Top 500 sites (as of October any password manager is only as strong as the security 2013) by manually visiting them and examining their of the weakest password manager it syncs with. login procedures. Of the 500 sites surveyed, 408 had 4.2 Injection Techniques login forms. 71 of these 408 sites, or 17.40%, use Sweep attacks rely on the attacker’s ability to modify a HTTP for loading the login page, but HTTPS for sub- page on the victim site by tampering with network traffic. mitting it. Some well known names are on this list of 71 The attacks are simplest when the vulnerable page is the sites, including ask.com, godaddy.com, reddit.com, login page itself. However, any page that is same-origin huffingtonpost.com, and att.com. with login page is sufficient, as all password managers Additionally, 123 (or 30.15%) of the sites used HTTP associate saved passwords with domains and ignore the both for loading the login page and for submitting it. This login page’s path. The attacker can inject a login form setup is trivially vulnerable to eavesdropping, but a vul- into any page in the origin of the actual login page and nerable password manager increases this vulnerability by launch a password extraction attack against that page. removing the need for a human to enter their password. We list a few viable injections techniques. For the purposes of our attacks, these sites can be thought HTTP login page. Consider a web site that serves its of as an especially vulnerable subclass of sites with a lo- login page over HTTP, but submits the login form over gin form served over HTTP. USENIX Association 23rd USENIX Security Symposium 455 Passwords for all these vulnerable websites can be eas- the login page is served over HTTPS. ily extracted from an autofilling password manager using Indeed, several prior works have found that users often the sweep attacks in the previous section. One could ar- tend to click through HTTPS warnings [43, 8]. The user gue that all these sites need to be redesigned to load and may decide to click through the warning and visit the site submit the login page over HTTPS. However, until that is anyway, but not enter any sensitive information. Never- done there is a need to strengthen password managers to theless, the user’s password manager autofills the pass- prevent these attacks. We discuss defenses in Section 5. word resulting in password extraction by the attacker, re- gardless of the user’s caution. All of the password man- Embedded devices I. Many embedded devices serve agers we tested fill passwords even when the user has their login pages over HTTP by default because the chan- clicked through an SSL warning, with the exception of nel is assumed to be protected by a WiFi encryption the desktop and Android versions of Chrome. protocol such as WPA2. Indeed, Gourdin et al. report that the majority of the embedded web interfaces still Active Mixed Content. Any HTTPS webpage con- use HTTP [26]. Similarly, internal servers in a corpo- taining active content (e.g., scripts) that is fetched over rate network may also serve web login pages over HTTP HTTP is also a potential vector. If rendering active mixed because access to these servers can only be done over a content is enabled in the user’s browser, any HTTPS page Virtual Private Network (VPN). containing active mixed content is vulnerable to injec- Sweep attacks are very effective against these devices: tion. Chrome, Firefox, and IE block active mixed content the password manager autofills the password even when by default but provide a user option to enable it. Safari, the underlying network connection is insecure. By in- Mobile Safari, and the Android stock browser allow ac- jecting JavaScript into the HTTP login page as above, a tive mixed content to be fetched and executed without coffee shop attacker can extract passwords for embedded any warnings. Several types of active mixed content, es- devices and corporate servers that the user has previously pecially those processed by browser plugins, are harder interacted with. to block. For example, embedding a Shockwave Flash (SWF) file over HTTP if not blocked correctly can be Embedded Devices II. Some home routers serve their used by a network attacker to inject arbitrary scripts [30]. login pages over HTTPS, but use are self-signed certifi- cates. An attacker can purchase a valid certificate for XSS Injection. A cross-site scripting vulnerability in the same common name as the router’s [38] or generate a page allows the attacker to inject JavaScript to modify its own self signed certificate. When the user’s machine the page as needed [24]. XSS vulnerabilities are listed connects to the attacker’s network, the attacker can spoof as one of the most common web vulnerabilities in 2013 the user’s home router by presenting a valid certificate for internet security threat report by Symantec [20]. If an the router’s web site. This allows the attacker to mount XSS vulnerability is present on any page of the victim the sweep attack and extract the user’s home router pass- site, the sweep attacks will work even if the site’s login word. page is served over HTTPS. For example, the attacker simply includes an iFrame or a redirect on the malicious Broken HTTPS. Consider a public site whose login hotspot landing page that links to the XSS page. The link page is served over HTTPS. In Section 2 we noted that uses the XSS vulnerability to inject the required login many password managers that autofill passwords auto- form and JavaScript into the page. matically do so even when the login page is loaded over Furthermore, an XSS vulnerability allows for a weaker a broken HTTPS connection, say due to a bad certificate. threat model than our coffee shop attacker. An ordinary This can be exploited in our redirect sweep attack: when web attacker can trick the user into visiting his site, then the browser is redirected to the victim site, the attacker launch the attack through the XSS vulnerability. This serves the modified login page using a self signed cert style of attack requires no access to the user’s network for that site. This modified login page contains a login and has been suggested previously by RSnake [37] and form and the JavaScript needed to exfiltrate the user’s Saltzman et al. [40]. password once it is autofilled by the password manager. These self signed certs will generate HTTPS warning Leftover Passwords. The user’s password manager in the browser, but if the redirect sweep attack happens as may contain leftover passwords from older, less secure part of the process of logging on to the hotspot, the user is versions of a site. An attacker could spoof the old site to motivated to click through the resulting HTTPS warning steal the leftover password. Unless the user is proactive messages. As a result the attacker can extract user pass- about removing older passwords, updating the security words from the password manager, even for sites where of the site does not protect the domain from this type of 456 23rd USENIX Security Symposium USENIX Association attack. For example, if a user’s password manager con- document.forms[0].action = attacker_addr; tained a password for Facebook from before its switch document.forms[0].submit(); } to HTTPS, an attacker could spoof an HTTP Facebook setTimeout(changer, 1000); login page to steal the password. In section 2.1 we showed that password managers that 4.3 Password Exfiltration automatically autofill passwords do so on page load and In the previous section we referred to JavaScript that show no warning to the user when the submitted form ac- exfiltrates the user’s password once it is autofilled by the tion differs from the action when the password was first password manager. Once the password manager has aut- saved. Thus, all password managers with automatic aut- ofilled the login form, the attacker must be able to access ofill are vulnerable to this exfiltration method. the filled-in credentials and send them to a server under 4.4 Attacks that need user interaction its control. We briefly describe two methods for accom- All of the attacks described thus far take advantage plishing this. of automatic autofill password managers to work when 4.3.1 Method #1: Stealth the user does not interact with the login form. How- Using stealth exfiltration, the attacker waits until the ever, the exfiltration techniques we described work re- login form is populated with the user’s credentials auto- gardless of how the login form was filled. If the user’s matically by a password manager, then steals the pass- password manager requires user input to fill passwords word by loading an attacker controlled page in an invis- and an attacker can trick the user to interact with the lo- ible iFrame and passing the credentials as parameters. gin form without them realizing it, the same exfiltration The following simple JavaScript does just that and works techniques can be used to steal the password as soon as with all password managers we tested: the password form is filled. We created a simple “clickjacking” attack [29, 39, 31]. function testPassword() { The attacker presents the user with a benign form seem- var password = ingly unrelated to the target site. Overlaying the benign document.forms[0].password.value; form is an invisible iFrame pointing to the target site’s if(password != "") { login page. The iFrame is positioned such that when a var temp = document.createElement("div"); user interacts with the benign form, they actually inter- temp.innerHTML += act with the invisible iFrame — in this case, when the "