Password managers: attacks and defenses

Password managers: Attacks and defenses Silver et al. USENIX 2014

As a regular reader of The Morning Paper, I’m sure you’re technically savvy enough to know not to use the same password across all the websites you use. To make good quality site-unique passwords practical therefore, you probably use a password manager. Maybe you remember that slight feeling of unease you had when you first started using one, since it puts all of your passwords in one place (and then for many password managers, syncs that ‘one place’ across devices and the cloud). Still, it’s better than the alternative right? In ‘Password managers: attacks and defenses,’ Silver et al. show us that many password managers contain one major vulnerability. Unfortunately, that vulnerability is the fact that they can be used to (auto)fill in password fields! Since this is a 2014 paper, it’s possible several of the attack vectors described have subsequently been closed (if you know of an updated report on this, please let us all know in the comments). My suspicion is that variations of these attacks remain.

TL;DR – don’t use autofill.

The evil coffee shop attacker

The attacker is assumed to be able to enact an active man-in-the-middle network attack – i.e., to interpose and modify arbitrary network traffic originating from or to a user’s machine. However, there is no requirement that the user explicitly visit or login to any particular site in order to steal the credentials for that site.

A rogue wifi router in a coffee shop (for example) is all that is needed – connect to it and your passwords could be gone.

We call this type of attacker the evil coffee shop attacker. These attacks require only temporary control of a network router and are much easier and thus more likely to happen in practice…. In many of our attacks the user need not interact with the victim web site and is unaware that password extraction is taking place.

Sweep attacks

The basic sweep attack works against any password manager that supports autofill of password fields. The target user connects to the WiFi hotspot controlled by the attacker.

When the user launches the browser, the browser is redirected to a standard hotspot landing page asking for user consent to standard terms of use. This is common behavior for public hotspots. Unbeknownst to the user however, the landing page contains invisible elements that implement the attack.

In other words, by the time you’re looking at the fully loaded landing page, most of your credentials could already be gone – in tests, about ten passwords can be extracted per second.

There are three basic ways the attacker can use the landing page to sweep passwords:

  1. In an iFrame sweep attack the landing page contains invisible iFrames pointing to arbitrary pages at multiple target sites. When the browser loads the frames, the attacker injects a login form and javascript into each of them (we’ll look at ways of doing that next). An autofilling password manager kindly auto-populates the corresponding password field with the user’s password.
  2. Instead of using iFrames, the attacker can use multiple windows instead. by requiring a window to open before the user can gain access to the wifi network, the user can be encouraged to disable any popup blocker. Multiple windows will be more noticeable than invisible iFrames, but injected javascript can e.g., minimise them, or hove them to the edge of the screen. They can be closed as soon as the password has been stolen.
  3. The third approach is to use a chain of redirects. When the user requests some page, the attacker responds with a redirect to a site for which the attacker wishes to learn the password. The injected javascript adds a login form, and hides the page details. As soon as the password manager autofills the password and it has been exfiltrated, the browser is redirected to the next target site, and so on in a chain, eventually loading the user’s originally requested page. The user sees a slow wifi connection…

As of 2014, the following table shows the tested password managers and which were vulnerable to these sweep attacks:


Sweep attacks rely on the attacker’s ability to modify a page on the victim site by tampering with network traffic. The attacks are simplest when the vulnerable page is the login page itself. However, any page that is same-origin with the login page is sufficient, as all password managers associated saved passwords with domains and ignore the login page’s path.

One easy setup to attack is sites that serve a login form over HTTP (bad practice), and only use HTTPS for the submission. As of October 2013, 17% of Alexa Top 500 sites with login forms did this. I’d like to think the number is less today but I don’t have the data.

Any HTTPS webpage with active content fetched over HTPP is also vulnerable (most browsers block this). Any XSS vulnerability on any page of the victim site will also work (even if the login page is served over HTTPS). In fact, an XSS vulnerability anywhere on the site enables the attack without even needing a rogue WiFi – so long as the web attacker can lure the victim into visiting a site the attacker controls.

Broken HTTPS connection (e.g. bad certificates) also lead to vulnerabilities as an attacker can serve the modified login page using a self-signed certificate. The browser will complain, but the user will often click through the warnings (especially when they occur as part of logging onto a WiFi network – or so they think).

A special prize goes to embedded devices which serve login pages over HTTP expecting to be on a private network protected by WiFi encryption, or (e.g.,) home routers that serve login pages over HTTPS but use self-signed certificates.


Once the javascript in the attackers page has the desired password, exfiltration is pretty straightforward. One approach is to load an invisible iFrame and pass the credentials as parameters, another is to modify the action of a login form to submit to an attacker-controlled site.

What if your password manager doesn’t autofill?

All of the attacks described thus far take advantage of automatic autofill password managers to work when the user does not interact with the login form. However, the exfiltration techniques we described work regardless of how the login form was filled. If the user’s password manager requires user input to fill password and an attacker can trick the user to interact with the login form without them realizing it, the same exfiltration techniques can be used to steal the password as soon as the password form is filled.

The authors describe a clickjacking attack that can work in this scenario – although of course we are now limited to stealing only one password at a time.

Supporting weaknesses in password managers

A number of password manager behaviours beyond simple autofilling help the attacker, these mostly seem to fall into the camp of password managers trying to be robust to changes in site implementation details. The following table provides a short summary, see section 2 in the paper for the longer explanation regarding each column.


The main proposed defence is secure filling, which requires a modified browser (and modified password managers to work with the modified browser).

if a login page is loaded over HTTP but submitted over HTTPS, no browser or password manager implementation provides security once the login form has been filled with the user’s password: JavaScript can read the password directly from the form or change the form’s action so that it submits to a password stealing page hosted by the attacker. The goal of secure filling is that even if an attacker injects malicious JavaScript into the login page, passwords autofilled by the password manager will remain secure so long as the form is submitted over HTTPS.

Secure filling requires:

  1. The password manager to store the action present in a login from when username and password were first saved
  2. When a login form is autofilled by a password manager, it becomes unreadable by JavaScript (hence the requirement for a modified browser).
  3. If username or password fields are modified (by the user or JavaScript) while an autofill is in progress, the autofill aborts clearing the password from the password field and making the field readable agin.
  4. Once a form with autofill is submitted and after all JavaScript code that is going to be run has run, the browser checks the form’s action matches the stored one and only submits if so.

Note this would also mean, for example, that we need to treat initial registration pages specially as they often include client-side validation of password strength (requiring js access).

We disclosed our results to the password manager vendors, prompting several changes to autofill policies. Due to our findings, LastPass will no longer automatically fill password fields in iFrames, and 1Password will no longer offer to fill passwords from HTTPS pages on HTPP pages.

There’s a recent and relevant post from Khad Young at 1Password explaining why 1Password doesn’t offer autofill capabilities that also discusses sweep attacks.

17 thoughts on “Password managers: attacks and defenses

  1. Great article. I would definitely like to see a revisit with current password manager builds and os versions to see if the vulnerabilities have indeed been countered.

    1. [Disclosure: I work for AgileBits, the makers of 1Password]

      As you see from the tables 1Password was never vulnerable to the major sorts of attacks described. (I’ve got a long pending comment explaining why, so I won’t repeat that here.) Elsewhere in the paper there were a few additional recommendations on how we (and others) could improve our anti-phishing measures. I recall writing the code to conform to one of those recommendations at the conference where that paper was presented. (I didn’t have a full build environment on my laptop, so I wasn’t able to demo it to David at the time, which would have been fun.)

      1. I should also add in answer to your question that the authors of the original paper informed the developers of the tested password managers well before the paper was published. For those that were vulnerable to the described attack, fixes were put into place swiftly (against the specific exploits). Often within days of the reports.

  2. Did LastPass have no vulnerabilities on Windows? (There are no entries for it)

    How does LastPass currently hold up on Android?

    Password Managers like LastPass should notify the user that they have disabled autofill on any page they detect a possible vulnerability on.

  3. [Disclosure: I work for AgileBits, the makers of 1Password.]

    I was at USENIX Security when David Silver presented this paper, which confirmed something that has been central to the design of 1Password from the outset We keep people in the loop. We see the web and web pages as hostile environments, and so we have designed our browser extension to be able to do and know only the minimum that it needs to do its job.

    Our terminology is a bit different. We refer to filling a form without any human interaction “automatic autofill”. We reserve the term “autofill” for how 1Password will fill in the form once you ask it to. But you must tell 1Password that you want it to fill the form on the page. (There are several ways to do that.)

    Well designed password managers reduce the chances that their users will fall victim to phishing attacks. The password manager checks to see that the it is only filling in to the correct page. But, as David and his co-authors point out, the protections that password managers offer against phishing aren’t perfect. (We have also long since implemented some of recommendations mentioned in the paper.)

    But there are two kinds of phishing sites or pages. Those that are designed to fool humans and those that are designed to fool password managers. The former, most password managers do a really good job at defending against. But there may still be rare cases where we fail to protect people from what they would also fall victim to without using a password manager.

    The latter – the content that is designed to fool password managers – are typically never seen by humans (these may be injected invisibly into pages). These are the sweep attacks that David and colleagues described. It would be bad for 1Password to fail to prevent a phishing attack that someone might otherwise be a victim of, but it would be terrible to enable a phishing attack that people would not otherwise be a victim to.

    And so in designing 1Password we fully recognized that password manager holds a lot of very sensitive data and so it will be a target of attack, and the web browser where some of those attacks will come. Our decision from the outset to never allow automatic autofill was part of this. We weren’t thinking about trying to defend against some specific sort of trick, but instead we sought to defend against the entire category by insisting that a human must instruct 1Password to fill a page.

    By the way: The actual talk was fantastic, so in addition to the paper, I would recommend that people watch David Silver’s presentation, which can be found from this page:

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.