Password Managers: Attacks and DefensesDavid Silver, Suman Jana, and Dan Boneh, Stanford University; Eric Chen andCollin Jackson, Carnegie Mellon his paper is included in the Proceedings of the23rd USENIX Security Symposium.August 20–22, 2014 San Diego, CAISBN 978-1-931971-15-7Open access to the Proceedings ofthe 23rd USENIX Security Symposiumis sponsored by USENIX

Password Managers: Attacks and DefensesDavid Silver Suman Jana Dan BonehStanford UniversityAbstractWe study the security of popular password managers andtheir policies on automatically filling in Web passwords.We examine browser built-in password managers, mobile password managers, and 3rd party managers. Weobserve significant differences in autofill policies amongpassword managers. Several autofill policies can leadto disastrous consequences where a remote network attacker can extract multiple passwords from the user’spassword manager without any interaction with the user.We experiment with these attacks and with techniques toenhance the security of password managers. We showthat our enhancements can be adopted by existing managers.1IntroductionWith the proliferation of Web services, ordinary usersare setting up authentication credentials with a largenumber of sites. As a result, users who want to setupdifferent passwords at different sites are driven to use apassword manager. Many password managers are available: some are provided by browser vendors as part ofthe browser, some are provided by third parties, andmany are network based where passwords are backed upto the cloud and synced across the user’s devices (suchas Apple’s iCloud Keychain). Given the sensitivity ofthe data they manage, it is natural to study their security.All the password managers (PMs) we examined do notexpect users to manually enter managed passwords on login pages. Instead they automatically fill-in the usernameand password fields when the user visits a login page.Third party password managers use browser extensionsto support autofill.In this paper we study the autofill policies of ten popular password managers across four platforms and showthat all are too loose in their autofill policies: they autofillthe user’s password in situations where they should notthereby exposing the user’s password to potential attackers. The results can be disastrous: an attacker can extractmany passwords from the user’s password manager without the user’s knowledge or consent as soon as the userconnects to a rogue WiFi network such as a rogue routerat a coffee shop. Cloud-based password syncing furtherexacerbates the problem because the attacker can potentially extract user passwords that were never used on theUSENIX AssociationEric Chen Collin JacksonCarnegie Mellon Universitydevice being attacked.Our results. We study the security of password managers and propose ways to improve their security. We begin with a survey of how ten popular password managers decide when to autofill passwords.Different password managers employ very different autofill policies, exposing their users to differentrisks. Next, we show that many corner cases in autofill policies can lead to significant attacks that enable remote password extraction without the user’sknowledge, simply by having the user connect to arogue router at a coffee shop. We believe that password managers can helpstrengthen credential security rather than harm it.In Section 5 we propose ways to strengthen password managers so that users who use them are moresecure than users who type in passwords manually.We implemented the modifications in the Chromebrowser and report on their effectiveness.We conclude with a discussion of related work on password managers.An example. We give many examples of password extraction in the paper, but as a warm-up we present oneexample here. Consider web sites that serve a login pageover HTTP, but submit the user’s password over HTTPS(a setup intended to prevent an eavesdropper from reading the password but actually leaves the site vulnerable).As we show in Section 4, about 17% of the Alexa Top500 websites use this setup. Suppose a user, Alice, usesa password manager to save her passwords for these sitesAt some point later, Alice connects to a rogue WiFirouter at a coffee shop. Her browser is directed to a landing page that asks her to agree to the terms of service,as is common in free WiFi hotspots. Unbeknownst toAlice, the landing page (as shown in Figure 1) containsmultiple invisible iFrames pointing to the login pages ofthe websites for which Alice has saved passwords. Whenthe browser loads these iFrames, the rogue router injectsJavaScript into each page and extracts the passwords autofilled by the password manager.23rd USENIX Security Symposium 449

This simple attack, without any interaction with theuser, can automatically extract passwords from the password manager at a rate of about ten passwords per second. Six of the ten password managers we examinedwere vulnerable to this attack. From the user’s point ofview, she simply visited the landing page of a free WiFihotspot. There is no visual indication that password extraction is taking place.we survey password managers in Google Chrome,1Password, and LastPass Tab. Android PMs: the default Android browser andChrome.All these password managers offer an “autofill” functionality, wherein the password manager automaticallypopulates the username and password fields within theuser’s web browser. We divide autofill strategies into twobroad categories: Automatic autofill: populate username and password fields as soon as the login page is loadedwithout requiring any user interaction. Passwordmanagers that support automatic autofill includeChrome (all platforms), Firefox, Safari, LastPass,Norton IdentitySafe, and LastPass Tab. Manual autofill: require some user interaction before autofilling. Types of interaction include clicking on or typing into the username field, pressinga keyboard shortcut, or pressing a button in thebrowser. Password managers that always requiremanual interaction include 1Password, Keeper, andKeePass.Figure 1: A sample landing page of a rogue WiFi hotspotcontaining invisible iFrames to the target sites. Note thatthe iFrames are actually invisible to the user and shownhere only for clarity.2Password managers: a surveyWe begin with a detailed survey of the autofill policiesimplemented in widely deployed password managers.The password managers we survey include: Desktop Browser PMs: Google Chrome 34, Microsoft Internet Explorer 11, Mozilla Firefox 29,and Apple Safari 7. 3rd Party PMs: 1Password [1], LastPass [5],Keeper [7], Norton IdentitySafe [6], and KeePass [4]. All of these besides KeePass providebrowser extensions that support password field autofill. iOS PMs: Mobile Safari’s password manager syncswith the desktop version of Safari through Apple’siCloud Keychain synchronization service. Sincemobile Safari does not support extensions, 3rd PartyPMs are separate applications with their own builtin web browser. In addition to Mobile Safari,450 23rd USENIX Security SymposiumInternet Explorer 11 uses a hybrid approach: it automatically autofills passwords on pages loaded over HTTPS,but requires user interaction on pages loaded over HTTP.We show in Section 4 that even this conservative behavior still enables some attacks.Some password managers require manual interactionfor autofill in specific situations: Chrome requires manual interaction if the passwordfield is in an iFrame. Chrome can read passwords stored in Mac OS X’ssystem-wide keychain, but will not automaticallyautofill them until they have been manually selectedby the user at least once. The first time Safari or Chrome on Mac OS X access a password in the system keychain, a systemdialog requests permission from the user. If theuser chooses “Always Allow”, this dialog will notbe shown again and the password will automaticallyautofill in the future. This dialog does not appear ifthe password was synchronized from another deviceusing iCloud Keychain. LastPass and Norton IdentitySafe provide nondefault configuration options to disable automaticautofill. In this paper we only discuss the defaultconfigurations for these password managers.USENIX Association

PlatformMac OS X10.9.3Safari ext.Safari ext.Safari ext.Windows8.1 ProIE addoniOS 7.1.1Android 4.3Password managerChrome 34.0.1847.137Firefox 29.0.1Safari 7.0.31Password 4.4LastPass 3.1.21Keeper 7.5.26IE 11.0.9600.16531KeePass 2.24IdentitySafe 2014.7.0.43Mobile Safari1Password 4.5.1LastPass Tab 2.0.7Chrome 34.0.1847.18Chrome 34.0.1847.114Android BrowserSameprotocoland toAutoManualAutoAutoAutoAutoDifferentprotocolNo FillNo FillNo FillManualManualManualNo FillManualAutoNo FillManualManualNo FillNo FillNo FillDifferentform actionon lAutoAutoManualAutoNo FillNo FillAutoDifferentform actionon toAutoManualAutoAutoAutoAutoautocomplete “off”AutoNo FillAutoManualAutoManualAuto/ManManualAutoNo FillManualAutoNo FillAutoNo FillBrokenHTTPSNo nualAutoAutoNo FillAutoTable 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 usedwhen the password was saved. Manual autofilling refers to autofilling a password after some user interaction, such asa click or tap on one of the form fields. No fill means that no autofilling of passwords takes place. The second to lastcolumn refers to autofill behavior when the password field’s autocomplete attribute is set to “off”. The last columnrefers to autofill behavior for a login page loaded over a bad HTTPS connection.2.1 Autofill policiesNext, we ask what happens when the PM is presentedwith a login page that is slightly different from the loginpage at the time the password was saved. Should the PMapply autofill or not? Different PMs behave differentlyand we survey the different policies we found. Table 1summarizes some of our findings.The domain and path. All password managers wetested allow passwords to be autofilled on any pagewithin the same domain as the page from which the password was originally saved. For example, a passwordoriginally saved on would be filled on This allows autofill to function on sites thatdisplay the login form on multiple pages, such as in apage header visible on all pages. It also allows autofillafter a site redesign that moves the login form.This feature means that an attacker can attack thepassword manager (as in Section 4) on the least-securepage within the domain. It also means that two siteshosted on the same domain (ie, jdoeand jsmith) are treated as a single siteby the password manager.Protocol: HTTP vs. HTTPS. Suppose the passwordwas saved on a login page loaded over one protocol (say,USENIX AssociationHTTPS), but the current login page is loaded over adifferent protocol (say, HTTP)? All other elements ofthe URL are the same, including the domain and path.Should the password manager autofill the password onthe current login page?Chrome, Safari, Firefox, and Internet Explorer allrefuse to autofill if the protocol on the current login pageis different from the protocol at the time the passwordwas saved. However, 1Password, Keeper, and LastPassall allow autofill after user interaction in this case. Notethat LastPass normally uses automatic autofill, so thisdowngrade to manual autofill on a different protocol wasimplemented as a conscious security measure. NortonIdentitySafe does not pay attention to the protocol. It automatically autofills a password saved under HTTPS ona page served by HTTP. As we show later on, any formof autofilling, manual or not, is dangerous on a protocolchange.Modified form action. A form’s action attribute specifies where the form’s contents will be sent to upon submission. form action "" method "post" One way an attacker can steal a user’s password is tochange the action on the login form to a URL under the23rd USENIX Security Symposium 451

attacker’s control. Therefore, one would expect password managers to not autofill a login form if the form’saction differs from the action when the password wasfirst saved.We consider two different cases. First, suppose thatat the time the login page is loaded the form’s actionfield points to a different URL than when the password was first saved. Safari, Norton IdentitySafe andIE (on HTTPS pages) nevertheless automatically autofillthe password field. Desktop Chrome and IE (on HTTPpages) autofill after some manual interaction with theuser. LastPass asks for user confirmation before fillinga form whose action points to a different origin than thecurrent page.Second, suppose that at the time the login page isloaded the form’s action field points to the correct URL.However, JavaScript on the page modifies the form action field so that when the form is submitted the data issent to a different URL. All of the password managerswe tested allow an autofilled form to be submitted in thiscase even though the password is being sent to the wronglocation. We discuss the implications of this in Section 4and discuss mitigations in Section 5.Password managers without automatic autofill requireuser interaction before filling the form, but none giveany indication to the user that the form’s action does notmatch the action when the credentials were first saved.Since a form’s action is normally not visible to the user,there is no way for the user to be sure that the form wassubmitting to the place the user intended.The effects of the action attribute on autofill behavioris captured in the third and fourth columns of Table 1.Autocomplete attribute A website can use the autocomplete attribute to suggest that autocompletion be disabled for a form input [3]:in Section 4, in our setting, the attacker controls the network and can modify the login form to turn the passwordinput’s autocomplete attribute on even if the victim website turns it off.In supporting browsers, the autocomplete attribute canbe used to prevent the password from being saved at all.This trivially defends against our attacks, as they requirea saved password. However, it is not a suitable defense ingeneral due to usability concerns. A password managerthat doesn’t save or fill passwords will not be popularamongst users.Broken HTTPS behavior. Suppose the password wassaved on a login page loaded over a valid HTTPS connection, but when visiting this login page at a later timethe resulting HTTPS session is broken, say due to a badcertificate. The user may choose to ignore the certificatewarning and visit the login page regardless. Should thepassword manager automatically autofill passwords inthis case? The desktop and Android versions of Chromerefuse to autofill passwords in this situation. IE downgrades from automatic to manual autofill. All other password managers we tested autofill passwords as normalwhen the user clicks through HTTPS warnings. As wewill see, this can lead to significant attacks.Modified password field name. All autofilling password managers, except for LastPass, autofill passwordseven when the password element on the login page has aname that differs from the name present when the password was first saved. Autofilling in such situations canlead to “self-exfiltration” attacks, as discussed in Section 5.2.1. LastPass requires manual interaction beforeautofilling a password in a field whose name is differentfrom when the password was saved. input autocomplete "off" . 2.2 Additional PM FeaturesSeveral password managers have the following security features worth mentioning:We find that Firefox, Mobile Safari, the default Android Browser, and the iOS version of Chrome respectthe autocomplete attribute when it is applied to a password input. If a password field has its autocomplete attribute set to “off”, these password managers will neitherfill it nor offer to save new passwords entered into it. Allof the other password managers we tested fill the password anyway, ignoring the value of the autocomplete attribute. LastPass ignores the attribute by default, but provides an option to respect it.Once the password manager contains a password for asite, the autocomplete attribute does not affect its vulnerability to the attacks presented in this paper. As describediFrame autofill. Norton IdentitySafe, Mobile Safariand LastPass Tab do not autofill a form in an iFrame thatis not same-origin to its parent page. Desktop Chrome requires manual interaction to autofill a form in an iFrameregardless of origin. Chrome for iOS and the Androidbrowser will never autofill an iFrame. Firefox, Safari,and Chrome for Android automatically autofill forms iniFrames regardless of origin.Safari and Mobile Safari will only autofill a single login form per top-level page load. If a page, combinedwith all of its iFrames, has more than one login form,only the first will be autofilled.We discuss the impact of these policies on security inSection 4.452 23rd USENIX Security SymposiumUSENIX Association

Visibility. Norton IdentitySafe does not automaticallyautofill a form that is invisible because its CSS displayattribute is set to “none” (either directly or inherited froma parent). However, it will automatically autofill a formwith an opacity of 0. Therefore, this defense does notenhance security.Autofill method. KeePass is unique amongst desktoppassword managers in that it does not integrate directlywith the browser. Instead, it can “autotype” a sequenceof keystrokes into whatever text field is active. For mostlogin forms, this means it will type the username, theTab key, the password, then the Enter key to populateand submit the form.Autofill and Submit. 1Password, LastPass, NortonIdentitySafe, and KeePass provide variants of “autofilland submit” functionality, in which the password managers not only autofills a login form but also automatically submits it. This frees the user from interacting withthe submit button of a login form and thus makes autofillmore convenient for the user.3Threat ModelIn the next section we present a number of attacksagainst password managers that extract passwords fromall the managers we examined. First, we define the attackers capabilities and goals. We only consider activeman-in-the-middle network attackers i.e. we assume thatthe adversary can interpose and modify arbitrary networktraffic originating from or destined to the user’s machine.However, unlike standard man-in-the-middle attacks, wedo not require the user to log into any target websites inthe presence of the attacker. Instead, the setup consistsof two phases:First, the user logs in to a number of sites and the attacker cannot observe or interfere with these logins. Theuser’s password manager records the passwords used forthese logins. For password managers that support syncing of stored passwords across multiple machines (e.g.,Apple’s iCloud KeyChain), users may even carry out thisstep on an altogether different device from the eventualvictim device.At a later time the user connects to a malicious network controlled by the attacker, such as a rogue WiFirouter in a coffee shop. The attacker can inject, block,and modify packets and its goal is to extract the passwords stored in the user’s password manager without anyaction from the user.We call this type of attacker the evil coffee shop attacker. These attacks require only temporary control of anetwork router and are much easier and thus more likelyUSENIX Associationto happen in practice. We show that even such weakman in the middle attackers can leverage design flaws inpassword managers to remotely extract stored passwordswithout the user logging into any website.The attacker has no software (malware) installed onthe user’s machine. We only assume the presence ofa password manager acting in the context of a webbrowser.4Remote extraction of passwords frompassword managersWe show that an evil coffee shop attacker can extractpasswords stored in the user’s password manager. Inmany of our attacks the user need not interact with thevictim web site and is unaware that password extractionis taking place. We discuss defenses in Section 5.4.1 Sweep attacksSweep attacks take advantage of automatic passwordautofill to steal the credentials for multiple sites at oncewithout the user visiting any of the victim sites. Forpassword managers backed by a syncing service (suchas Apple’s iCloud Keychain) the attacker can extract sitepasswords even if the user never visited the site on thatdevice. These attacks work in password managers thatsupport automatic autofill, highlighting the fundamentaldanger of this feature.Sweep attacks consist of three steps. First, the attackermakes the user’s browser visit an arbitrary vulnerablewebpage at the target site without the user’s knowledge.Next, by tampering with network traffic the attacker injects JavaScript code into the vulnerable webpage as it isfetched over the network using one of the methods described in Section 4.2. Finally, the JavaScript code exfiltrates passwords to the attacker using the techniques inSection 4.3.In the sweep attacks we implemented, the user connects to a WiFi hotspot controlled by the attacker. Whenthe user launches the browser, the browser is redirectedto a standard hotspot landing page asking for user consent to standard terms of use. This is common behaviorfor public hotspots. Unbeknownst to the user, however,the landing page contains invisible elements that implement the attack.iFrame sweep attack. Here the innocuous hotspotlanding page contains invisible iFrames pointing to thearbitrary pages at multiple target sites. When the browserloads these iFrames, the attacker uses his control of therouter to inject a login form and JavaScript into eachiFrame using the methods described in Section 4.2. Aswe will see, injecting a login form and JavaScript is not23rd USENIX Security Symposium 453

difficult and can be done in several different ways. Allthat is needed is some vulnerable page on the target site.It is especially easy for sites that serve their login pageover HTTP (but submit passwords over HTTPS), whichis a common setup discussed in the next section.As each iFrame loads, the password manager will automatically populate the corresponding password fieldwith the user’s password. The injected JavaScript in eachiFrame can then steal and exfiltrate these credentials.Our experiments show that this method can extractpasswords, unbeknownst to the user, at a rate of about tenpasswords per second. To prevent the user from clickingthrough the landing page before the attacks are done, thelanding page includes a JavaScript animated progress barthat forces the user to wait until the attacks complete.We also find that the password extraction process canbe made more efficient by arranging the iFrames in ahierarchical structure instead of adding one iFrame tothe top-level page for each target website. Adding allthe iFrames to the top-level page would create large increases in both the amount of traffic on the network andthe amount of memory used by the victim’s browser. Hierarchical arrangement of the iFrames can avoid such issues. The top-level iFrame contains most of the codefor the attack and dynamically spawns child frames andnavigates them to the target pages. This technique allows the iFrames to load asynchronously and thus ensures that network and memory usage remain reasonablefor the duration of the attack.Chrome (all platforms) is the only automatic autofillpassword manager that is not vulnerable to the iFramebased attack, because they never automatically autofillpasswords in iFrames. All the other automatic autofillpassword managers are vulnerable to this attack. Eventhough the autofill policies of Norton IdentitySafe, Safari, Mobile Safari, and LastPass Tab described in Section 2.2 restrict the number of passwords that can bestolen in a single sweep to 1, they remain vulnerable.Window sweep attack. A variant of the sweep attackuses windows instead of invisible iFrames. If the attackercan trick users into disabling their popup blocker (e.g.,by requiring a window to open before the user can gainaccess to the WiFi network), the landing page can openeach of the victim pages in a separate window. This ismore noticeable than the iFrame-based approach, but theJavaScript injected into each victim page can disguisethese windows to minimize the chances of detection.Techniques for disguising the windows include minimizing their size, moving them to the edge of the screen,hiding the pages’ contents so that they appear to the useras blank windows, and closing them as soon as the pass-454 23rd USENIX Security Symposiumword has been stolen.Nearly all automatic autofill password managers, including desktop Chrome, are vulnerable to the windowbased attack. Only LastPass Tab is not vulnerable, as itdoes not support popup windows at all. Hence, althoughiFrames make the sweep attack easier, they are not required.Redirect sweep attack. A redirect sweep attack enables password extraction without any iFrames or separate windows. In our implementation, once the user connects to a network controlled by the attacker and requestsan arbitrary page (say,, the network attacker responds with an HTTP redirect to some vulnerable pageon the target site (say, The user’s browser receives the redirect and issues a request for the page The attacker allows the page to load, but injects alogin form and JavaScript into the page, as described inSection 4.2. The injected JavaScript disguises the page(for example, by hiding its body) so that the user doesnot see that is being visited.When the user’s browser loads the page from,the vulnerable password manager will automatically autofill the login form with the credentials for, whichthe injected JavaScript can then exfiltrate. Once done,the injected JavaScript redirects the user’s browser to thenext victim site, (say and exfiltrates the user’spassword at in the same way. When sufficientlymany passwords have been exfiltrated the attacker redirects the user’s browser to the original page requested bythe user ( attack leaves small indications that password extraction took place. While the attack is underway theuser’s address bar will display the address of the attackedsite, and the attacked site will remain in the user’s history. However, as long as the body of the page itself isdisguised, most users will not notice these small visualclues.All of the automatic autofill password managers wetested were vulnerable to this attack.Summary. Table 2 describes which password managers are vulnerable to these sweep attacks.Attack amplification via password sync. Most password managers offer services that synchronize users’passwords between different devices. These passwordsynchronization services can potentially result in password extraction from devices without them ever havingvisited the victim site.Suppose the user’s password manager syncs betweentheir desktop and tablet, and will automatically autofilla password synced from another device without user in-USENIX Association

PlatformMac OS X 10.9.3Safari ext.Safari ext.Safari ext.Windows 8.1 ProIE addoniOS 7.1.1Android 4.3Password ManagerChrome 34.0.1847.137Firefox 29.0.1Safari 7.0.31Password 4.4LastPass 3.1.21Keeper 7.5.26Internet Explorer 11.0.9600.16531KeePass 2.24Norton IdentitySafe 2014.7.0.43Mobile Safari1Password 4.5.1LastPass Tab 2.0.7Chrome 34.0.1847.18Chrome 34.0.1847.114Android BrowseriFrame sweep SingleWindow sweep Redirect sweep HTTPSHTTPSHTTPSSOSingle, SO SOTable 2: Vulnerability to sweep attacks. indicates vulnerability without restriction. HTTPS indicates vulnerabilityonly on pages served over HTTPS. Single indicates a single site is vulnerable per top-level page load. SO indicatesvulnerability when the page containing the iFrame is same-origin with the target page in the iFrame.teraction. Suppose further that the site is vulnerable to network attacks and thus to the attacks describedabove. The user is careful and only ever visits ontheir desktop, which never leaves the user’s safe homenetwork. However, when the user connects their tablet tothe attacker’s WiFi network at a coffee shop, the attackercan launch a sweep attack on the user’s tablet and extractthe user’s password for even though the user hasnever visited on their tablet.We tested Apple’s iCloud Keychain, Google ChromeSync, Firefox Sync, and LastPass Tab, and found all ofthem to be vulnerable to this attack. In general, any password manager that automatically autofills a passwordsynced from another device will be vulnerable to thistype of attack amplification. Therefore, the security ofany password manager is only as strong as the securityof the weakest password manager it syncs with.4.2 Injection TechniquesSweep attacks rely on the attacker’s ability to modify apage on the victim site by tampering with network traffic.The attacks are simplest when the vulnerable page is thelogin page itself. However, any page that is same-originwith login page is sufficient, as all password managersassociate saved passwords with domains and ignore thelogin page’s path. The attacker can inject a login forminto any page in the origin of the actual login page andlaunch a password extraction attack against that page.We list a few viable injections techniques.HTTP login page. Consider a web site that serves itslogin page over HTTP, but submits the login form overUSENIX AssociationHTTPS. While this setup prote

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