I’ve spent a lot of time trying to understand the attack surface of popular password managers. I think I’ve spent more time analyzing them than practically anybody else, and I think that qualifies me to have an opinion!
First, let’s get a few things out of the way. For some reason, few subjects can get heated faster than passwords. Maybe politics and religion, but that’s about it. It’s okay if you don’t like my opinion.
Second, everyone needs to be using unique passwords. You don’t have to use a password manager to do that, whatever system works for you is fine. If you want to use a notebook in a desk drawer, that’s totally acceptable.
Okay, let’s begin.
If you just want some advice on what to use, skip to the conclusion.
Problems
Conceptually, what could be simpler than a password manager? It’s just a trivial key-value store. In fact, the simplest implementations are usually great. Good examples of simple and safe password managers are keepass and keepassx, or even pass if you’re a nerd.
Things start to go wrong when you want integration with other applications, or when you want data synchronized by an untrusted intermediary. There are safe ways to achieve this, but the allure of recurring subscription fees has attracted businesses to this space with varying degrees of competence. I’m generally skeptical of these online subscription password managers, and that’s going to be the focus of the rest of this article.
Bad Advice
I often say that “use a password manager” is bad advice. That’s because it’s difficult to tell the difference between a competent implementation and a naive one. The tech press can review usability and onboarding experience, but can’t realistically evaluate any security claims, so how do you propose users tell the difference? For that reason, I think “use a password manager” is so vague that it’s dangerous.
A good analogy is telling someone with a headache to pop any pills they find in the medicine cabinet. Maybe they’ll get lucky and find an aspirin, or maybe they won’t and you’ll be making a call to poison control.
Advice on this topic needs to be specific. It’s better to recommend implementations that are well designed, rather than general product categories. This position is surprisingly contentious, many people argue any password manager is acceptable and that I’m sowing fear by actually evaluating vendor claims. I remain unconvinced.
Attack Surface
My primary area of interest is how remote attackers can interact with your password manager.
I’m not interested in things like testing how resistant encrypted blobs are to offline cracking. This might be a valid concern for some, but in most cases if an attacker is in a position to access or tamper with encrypted state, then you were in trouble whether you used a password manager or not.
There are two common issues I run into, the first is that trusted user interface elements are injected into potentially hostile websites. The second is that different components ipc over web-accessible channels (e.g. WebSockets, postMessage, etc.) without adequate mutual authentication.
Lets discuss user interface elements first.
Hostile Environments
Most online password managers use content scripts, javascript that is inserted into every website you visit. It’s really easy to write content scripts, but really tough to make them tamper resistant. That’s kind of a problem, because they’re going to be hosted in hostile environments.
A good example of the kind of subtle ways this can go wrong is a bug like this. How isolated worlds interact is complicated enough, but password managers make matters even worse by blurring the distinction between user interface and content.
Chrome vs Content
There are two primary components that make up your browser interface, the chrome (confusingly, the term has nothing to do with Google Chrome) and the content area. The chrome contains things like the address bar, tabs and back button. These components can be trusted, and websites can’t interfere with them. Conversely, anything inside the content area can be controlled by the website and therefore it can’t be trusted.
Most password managers blur this distinction by drawing their UI in the content area. There is just no way to do this safely, and it’s trivial to make demos that show why.
Frames
Okay, but it’s not unusual to have different parts of the content area with different privileges, that’s basically how iframes work. That doesn’t make it safe though, and you’re probably familiar with X-Frame-Options, it’s a way for websites to opt-out of being framed. Most security conscious websites will do exactly that, because it’s just too easy for attackers to trick you into interacting with frames in unintended ways.
These are sometimes called redress attacks or clickjacking (groan, I hate that term). There’s a thorough analysis of the attack in the Browser Security Handbook.
If redress attacks are problematic enough to make everyone disable framing, should the software tasked with protecting your passwords also opt-out? That was a trick question, they can’t!
A Brief Illustration
As I’m writing this, I happened to see a commercial for a new password manager called Nordpass. Let’s use it as a testcase and take a look. All online password managers work in a similar way, this isn’t specific to any one implementation.
Note:I’m deliberately trying to avoid finding specific vulnerabilities so that I don’t have to start the tedious formal disclosure process. This is just a general illustration of weaknesses inherent in these designs.
After installing the extension I immediately see that it uses content scripts to add interface elements to login forms.
In general, websites can interact with that UI, and quick testing confirms that is true here. It looks like I can style those elements too, that means trivial redress is possible.
This problem is pervasive among online password managers, you can never be sure if you’re interacting with a website or your password manager. Let’s make a quick demo.
Here is a quick example, you can try it out yourself if you have Nordpass installed, please excuse my terrible design skills.
This is a fundamental and unfixable problem with designs like this.
I’ve found many real, exploitable vulnerabilities in the way these UI elements work. Trivial ones like this, or this. Sometimes interaction isn’t even necessary.
Interprocess Communication
We’ve already established that one component of online password managers must be injected into potentially hostile environments. How can those components communicate with other components?
One naive solution would be to just use XHR or WebSockets to a local HTTP endpoint. This sounds appealing to developers, they’re the native way to communicate on the web. The problem with this solution is it’s very difficult to differentiate between your content script, and a hostile script running on the same page but a different world.
Essentially every implementation I’ve looked at has got this wrong, resulting in critical game-over vulnerabilities. Some worst offenders are bugs like this, this.
Vendors come up with all kind of hacky solutions to this, often involving inherently racy background scripts that try to verify a tabs origin.
Sandboxes
Another gripe I have with online password managers is that they render browser sandboxes less effective. Modern browsers use a sandbox architecture to isolate components that can go wrong.
The problem is that online password managers effectively inject privileged components into these sandboxed processes with extensions. The purpose of sandboxing is to isolate potentially compromised components from each other, but if you stuff all your most valuable secrets inside the sandbox - then what’s the point?
I worry that people don’t understand the tradeoff they’re making here.
Vendor Claims
Despite what your vendor says, if their network is compromised, the attacker can read your passwords. Here are some selected marketing claims from password manager vendors:
“No one apart from you, not even [us], has access to your passwords.”
“[We keep] your information private, secure and hidden (even from us).”
“Your data is secured in a way that only you can view and manage it. [Our] employees can’t”
etc, etc.
These claims are all nonsense. An attacker (or malicious insider) in control of the vendor’s network can change the code that is served to your browser, and that code can obviously access your passwords. This isn’t farfetched, altering the content of websites (i.e. defacement) is so common that it’s practically a sport.
The reality is that you have to trust your vendor to maintain their infrastructure and keep it safe. The existence of encryption (“bank grade” or not) does not alter this.
Perhaps you think this isn’t a big deal, you already trusted them when you installed their software. Fine, but these claims are front and center in all marketing, so vendors must believe their customers care about it. I think these claims are bending the truth to assuage legitimate concerns.
More Claims
It’s easy to poke holes in marketing fluff, but here are some other fun ones I noticed from real password manager vendors.
Keystroke encryption protects everything you type from being read by cybercriminals.Oh, okay.
Many of the .NET assemblies […] are obfuscated, so even using a disassembler users are unable to view critical areas of methods/functions/classes.Well, I certainly feel safer.
etc, etc.
Conclusion
If you want to use an online password manager, I would recommend using the one already built into your browser. They provide the same functionality, and can sidestep these fundamental problems with extensions.
I use Chrome, but the other major browsers like Edge or Firefox are fine too. They can isolate their trusted UI from websites, they don’t break the sandbox security model, they have world-class security teams, and they couldn’t be easier to use.
No doubt there will be many people reading this who don’t like this advice. All I can say is I’ve heard all the arguments, and stand by my conclusions.
