Password Managers: Attacks and Defenses

Password Managers: Attacks and Defenses David Silver1, Suman Jana1, Eric Chen2, Collin Jackson2, and Dan Boneh1 1Stanford University 2Carnegie Mellon University Abstract at a coffee shop. Cloud-based password syncing further exacerbates the problem because the attacker can poten- We study the security of popular password managers and tially extract user passwords that were never used on the their policies on automatically filling in Web passwords. device being attacked. We examine browser built-in password managers, mobile password managers, and 3rd party managers. We Our results. We study the security of password man- observe significant differences in autofill policies among agers and propose ways to improve their security. password managers. Several autofill policies can lead • We begin with a survey of how ten popular pass- to disastrous consequences where a remote network at- word managers decide when to autofill passwords. tacker can extract multiple passwords from the user’s Different password managers employ very differ- password manager without any interaction with the user. ent autofill policies, exposing their users to different We experiment with these attacks and with techniques to risks. enhance the security of password managers. We show that our enhancements can be adopted by existing man- • Next, we show that many corner cases in aut- agers. ofill policies can lead to significant attacks that en- able remote password extraction without the user’s 1 Introduction knowledge, simply by having the user connect to a With the proliferation of Web services, ordinary users rogue router at a coffee shop. are setting up authentication credentials with a large number of sites. As a result, users who want to setup • We believe that password managers can help different passwords at different sites are driven to use a strengthen credential security rather than harm it. password manager. Many password managers are avail- In Section 5 we propose ways to strengthen pass- able: some are provided by browser vendors as part of word managers so that users who use them are more the browser, some are provided by third parties, and secure than users who type in passwords manually. many are network based where passwords are backed up We implemented the modifications in the Chrome to the cloud and synced across the user’s devices (such browser and report on their effectiveness. as Apple’s iCloud Keychain). Given the sensitivity of the data they manage, it is natural to study their security. We conclude with a discussion of related work on pass- All the password managers (PMs) we examined do not word managers. expect users to manually enter managed passwords on lo- An example. We give many examples of password ex- gin pages. Instead they automatically fill-in the username traction in the paper, but as a warm-up we present one and password fields when the user visits a login page. example here. Consider web sites that serve a login page Third party password managers use browser extensions over HTTP, but submit the user’s password over HTTPS to support autofill. (a setup intended to prevent an eavesdropper from read- In this paper we study the autofill policies of ten pop- ing the password but actually leaves the site vulnerable). ular password managers across four platforms and show As we show in Section 4, about 17% of the Alexa Top that all are too loose in their autofill policies: they autofill 500 websites use this setup. Suppose a user, Alice, uses the user’s password in situations where they should not a password manager to save her passwords for these sites thereby exposing the user’s password to potential attack- At some point later, Alice connects to a rogue WiFi ers. The results can be disastrous: an attacker can extract router at a coffee shop. Her browser is directed to a land- many passwords from the user’s password manager with- ing page that asks her to agree to the terms of service, out the user’s knowledge or consent as soon as the user as is common in free WiFi hotspots. Unbeknownst to connects to a rogue WiFi network such as a rogue router Alice, the landing page (as shown in Figure 1) contains multiple invisible iFrames pointing to the login pages of • iOS PMs: Mobile Safari’s password manager syncs the websites for which Alice has saved passwords. When with the desktop version of Safari through Apple’s the browser loads these iFrames, the rogue router injects iCloud Keychain synchronization service. Since JavaScript into each page and extracts the passwords aut- mobile Safari does not support extensions, 3rd Party ofilled by the password manager. PMs are separate applications with their own built- This simple attack, without any interaction with the in web browser. In addition to Mobile Safari, user, can automatically extract passwords from the pass- we survey password managers in Google Chrome, word manager at a rate of about ten passwords per sec- 1Password, and LastPass Tab. ond. Six of the ten password managers we examined • Android PMs: the default Android browser and were vulnerable to this attack. From the user’s point of Chrome. view, she simply visited the landing page of a free WiFi hotspot. There is no visual indication that password ex- All these password managers offer an “autofill” func- traction is taking place. tionality, wherein the password manager automatically 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 password 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 before autofilling. Types of interaction include clicking on or typing into the username field, pressing a keyboard shortcut, or pressing a but- ton in the browser. Password managers that always require manual interaction include 1Password, Keeper, Password Safe, and KeePass. Figure 1: A sample landing page of a rogue WiFi hotspot Internet Explorer 11 uses a hybrid approach: it automat- containing invisible iFrames to the target sites. Note that ically autofills passwords on pages loaded over HTTPS, the iFrames are actually invisible to the user and shown but requires user interaction on pages loaded over HTTP. here only for clarity. We show in Section 4 that even this conservative behav- ior still enables some attacks. Some password managers require manual interaction 2 Password managers: a survey for autofill in specific situations: We begin with a detailed survey of the autofill policies implemented in widely deployed password managers. • Chrome requires manual interaction if the password The password managers we survey include: field is in an iFrame. • Chrome can read passwords stored in Mac OS X’s • Desktop Browser PMs: Google Chrome 34, Mi- system-wide keychain, but will not automatically crosoft Internet Explorer 11, Mozilla Firefox 29, autofill them until they have been manually selected and Apple Safari 7. by the user at least once. • 3rd Party PMs: 1Password [1], LastPass [29], • The first time Safari or Chrome on Mac OS X ac- Keeper [28], Norton IdentitySafe [26], Password- cess a password in the system keychain, a system Safe [32], and KeePass [27]. All of these besides dialog requests permission from the user. If the PasswordSafe and KeePass provide browser exten- user chooses “Always Allow”, this dialog will not sions that support password field autofill. be shown again and the password will automatically autofill in the future. This dialog does not appear if Modified form action. A form’s action attribute spec- the password was synchronized from another device ifies where the form’s contents will be sent to upon sub- using iCloud Keychain. mission. • LastPass and Norton IdentitySafe provide non- <form action="example.com" method="post"> default configuration options to disable automatic autofill. In this paper we only discuss the default One way an attacker can steal a user’s password is to configurations for these password managers. change the action on the login form to a URL under the 2.1 Autofill policies attacker’s control. Therefore, one would expect password managers to not autofill a login form if the form’s Next, we ask what happens when the PM is presented action differs from the action when the password was with a login page that is slightly different from the login first saved. page at the time the password was saved. Should the PM We consider two different cases. First, suppose that apply autofill or not? Different PMs behave differently at the time the login page is loaded the form’s action and we survey the different policies we found. Table 1 field points to a different URL than when the pass- summarizes some of our findings. word was first saved. Safari, Norton IdentitySafe and The domain and path. All password managers we IE (on HTTPS pages) nevertheless automatically autofill tested allow passwords to be autofilled on any page the password field. Desktop Chrome and IE (on HTTP within the same domain as the page from which the pass- pages) autofill after some manual interaction with the word was originally saved. For example, a password user. LastPass asks for user confirmation before filling originally saved on https://www.example.com/aaa. a form whose action points to a different origin than the php would be filled on https://www.example.com/ current page. bbb.php. This allows autofill to function on sites that Second, suppose that at the time the login page is display the login form on multiple pages, such as in a loaded the form’s action field points to the correct URL.

Load more