Sign Up for Our Newsletter
* indicates required


Password Manager Vulnerability Silently Giving Up Credentials

If you’re not using a 3rd party password manager, now’s a good time to start

Disclaimer: Right off the bat, let me say that I don’t have a dog in this fight. I don’t work for, nor have received any money from any company that makes a password manager, either personally or through Threatcare. My opinion here is entirely based off my personal experiences and testing with the browsers and password managers I have at my disposal. I have concluded that there is a password manager vulnerability that can affect many users.

The other day, Troy Hunt (best known for his HaveIBeenPwned website/service) shared an article about a new trick advertisers have been spotted using: creating fake login forms to get password managers to give up credentials. I read up on the issue and summarized it in my own tweet, which went a bit nuts and made my Twitter account difficult to use for a few days. There undoubtedly a large number of users that could be affected by this password manager vulnerability.

The varied responses to this tweet led me to do some of my own research, which I’m happy to be able to now share. If you just want a list of which password managers can be safely trusted with your passwords, just skip to the bottom of this post.


The problem: native browser password managers (with one exception: Vivaldi) will auto-fill your username and password into invisible forms designed to trick them. In this article, it is critically important to understand the difference between a password manager built into a web browser (Firefox, Chrome, Edge, Safari and every other browser has one) and a third-party password manager that integrates into web browsers via browser plugins.

The scope: This only works for the same domain — e.g. if your browser is at, your browser’s password manager won’t auto-fill credentials for The problem arises when includes third party scripts on its website and’s javascript is able to collect credentials on This password manager vulnerability raises alarms, enabling an autofill from different sites using the same third party script.

The solution: Migrate all saved passwords to a third party password manager (e.g. 1Password, LastPass, Dashlane, etc…). All saved passwords must be deleted from browser password managers to effectively mitigate this issue. Even if you disable your browser’s password manager, in most cases, it will still auto-fill any saved credentials.

Attack Surface

Before we get much farther, we need to touch on the attack surface here. This is not a ‘cross-domain’ attack and doesn’t require cross-site scripting (XSS). In other words, this doesn’t involve stealing your credentials from JavaScript running on Rather, the concern here is that third party scripts on the same domain can steal credentials. If you’re using a native browser’s password manager, third-party JavaScript running on can steal your credentials. Princeton’s Center for Information Technology Policy (CITP) discovered this issue and has a good writeup on how it works.

And that doesn’t sound too bad, does it? After all, most of the sites that run ads and other 3rd party scripts are ones where we could all care less if someone stole our password, right? What do we care if someone nabs our password? Except that isn’t the case — more and more frequently, almost every website runs both native and third party scripts. Add to that the commonality of XSS flaws that allow scripts to be loaded or stored by an attacker and the attack surface grows to include a large portion of the web. A small credit union I do business with, for example, is pulling scripts from four external sources and is loading local scripts obtained as free open source software (FOSS).

So what we’ve seen so far are two ad-tech companies that have created JavaScript to capture the usernames belonging to website visitors. It is trivial, however, for malicious parties to grab passwords as well, as demonstrated by Princeton’s researchers. The ease of this attack makes it highly likely that we’ll see malicious parties trying to get scripts loaded onto popular websites, either through injection flaws or through ad networks.

Threat Mapping: Where can bad scripts come from?

Following is a brief breakdown of sources for malicious scripts. Any of these scripts could potentially take advantage of this password manager vulnerability:

  • Injection flaws in websites (XSS, file upload, etc)
  • 3rd party FOSS scripts, like JQuery, that are loaded locally
  • JQuery plugins are apparently common — Terry Richardson’s Time Picker, for example. How resilient would his website or plugin be to an adversary with professional hacking skills? How much due diligence is a web developer going to do before downloading his script and building it into a website?
  • Remote scripts — this is a broad category that includes everything from Google Analytics to and advertisers.

Password Manager Showdown

At the time I initially did this research (late December, 2017), all native web browser password managers, gave up their credentials. Vivaldi was the ONLY browser we found that offers a safe option here, that can prevent auto-fill. Like third party password managers, it requires a manual click on a visual element before giving up the goods.

Here are my findings from late December. Given the popularity of tweets around this topic, it will be interesting to revisit and retest in a month or two to see if any browsers have updated how they handle this password manager ‘vulnerability’?

Outlook on Ads and Password Manager Vulnerability

Ads on the web and website monetization in general is a mess, currently. The Brave web browser has an integrated payment system for websites. Google is going live with an ad-blocker in Chrome on February 15th. Experiments with crypto-coin mining alternatively did well (on ThePirateBay, of all places) and blew up (thanks to media headlines making a single Starbucks in Brazil sound like the entire chain).

The state of Internet advertising is a bigger topic, best left for a separate post. Good news: that post is already in the works.