LastPass fixes some browser-based impersonation weaknesses

The password-management company responded to a security researcher by battening down the hatches. But messages in a browser can't be trusted.

last pass breach

Sean Cassidy is a LastPass user and a security researcher. About a week ago, he posted a blog entry about something he realized in using LastPass: Because of its reliance on browser-based alerts and logins on the desktop, rather than using a separate interface or native app login, it was easy to spoof.

He’d sorted out the details months ago, but he writes that miscommunication and delays led to LastPass not fixing all the problems before he presented his work at ShmooCon, a security event, in mid-January. Since then, Last Pass has reworked remaining issues, provided a more thorough explanation to its users, and explained its future direction to better reduce this kind of spoofing attack.

At heart, it just reemphasizes something that’s been known for years: A browser’s content portion—its viewport—can’t be trusted.

Browser beware

Since the dawn of anything worth spoofing on the World Wide Web, sites have appeared that impersonated others. The rise of secure web connections mitigated that, as browsers would warn users when an intended destination was rerouted—at least in some cases. Browser exploits, malware, and “evil twin” hotspots that could poison local networks have been used to push fake sites to users, too.

And phishing remains a constant problem. I imagine at least billions of messages go out each day that try to get people to click a link that takes them to a site that then attempts to snarf their login credentials or steal their identity.

The LastPass problem runs in parallel with this, though it has a different cause and the company has released mitigation. LastPass’s browser extensions push messages into the viewport, the browser’s main display area, using the same underlying structure and style code available to webpages.

Cassidy noted this is a problem, because of a sequence of not-improbable actions:

  • A user is phished or visits a malicious site, which can be any site—even one with seemingly legitimate content, but which has a malicious script.

  • That site uses JavaScript to determine whether LastPass is installed. (LastPass has a free version and is in wide use.)

  • If LastPass is installed, it draws a message in the viewport that looks exactly like a LastPass alert, which tells a user that their LastPass session has expired.

  • A user clicks the link, is taken to another website, but one that has a legitimate-looking address. (Cassidy registered one that might fool people, but there are billions of domains that could be registered that wouldn’t look skeevy, either.)

  • At that site, a user enters their credentials in what appears to be a LastPass login, again drawn in the viewport and which looks essentially identical to the real one, which uses a non-viewport pop-down menu.

  • The site uses LastPass’s API (application programmer’s interface) to query LastPass servers and access or retrieve a user’s password vault.

LastPass says it’s added steps that will prevent this sequence and ones like it. First off, an attacking site can’t log the user out of its system, so there’s a mismatch between an active LastPass icon in the browser and the message.

lastpass login Sean Cassidy

This screenshot from Sean Cassidy's blog post shows a spoofed LastPass login page in Chrome—the domain "" is relatively close to the real protocol, "chrome-extension." 

Next, because LastPass monitors keystrokes (locally, without sending them back to its servers), it can tell when you type the master password for your account. It now stops you and warns you before submission if it’s happening anywhere but on its site. It also warns users if the master password is used for any other purpose, like on another website. (Cassidy notes that it relies on the same viewport, so a malicious attacker can block that warning, too.)

Finally, LastPass has beefed up how it allows logins from locations that haven’t previously been used and approved, both for single-factor (password only) and two-factor logins. Before the login can complete, a receives a verification email and has to click a link in it. LastPass notes that a user would have to have compromised email for that step to be hijacked, and this impersonation attack doesn’t rely on obtaining other credentials. Though it could ultimately be coupled with that, such a connection dramatically decreases its potential yield of password vaults.

LastPass initially only protected password-only logins, allowing a verification bypass. Cassidy notes that because the malicious site can present an interface for the second factor, this made it less secure. LastPass has since added a requirement for verification email for all accounts.


The fundamental problem isn’t in LastPass’s security. Cassidy didn’t break into its servers or exploit a weakness in its plug-in. Rather, it exploits what’s a misplaced trust that messages in the viewport are as valid as messages produced in other ways in a browser or the operating system.

LastPass says in its FAQ entry on Cassidy’s “LostPass” (as he dubbed it) that they’re working to break out of the viewport, though they are stymied in part by Google Chrome. Chrome is a quite locked-down browser, and praised for it. The current design doesn’t allow plug-ins to place messages anywhere but within the viewport, which limits what LastPass can do.

Some of LastPass’s competitors, like 1Password, adopted an entirely different approach which bypasses this particular social-engineering weakness. 1Password runs a background process that effectively triggers a pop-over window with its interface, which generally works (though I sometimes see timing issues and delays) while avoiding the viewport. LastPass’s extension does have its own outside-the-viewport menu, but that’s not where errors and other messages get pushed.

In the Harry Potter books, there’s a line that never made much sense to me, where Arthur Weasley quotes something he’s told his children repeatedly: “Never trust anything that can think for itself if you can’t see where it keeps its brain.” (This never made consistent sense because, for instance, where is the Sorting Hat’s brain?)

I’m afraid we should have adopted this rubric for the web long ago: Never trust anything that displays in a browser, because we can’t see where it keeps its “brain.” We don’t know what drew it; we can’t trust it; and it’s time to move beyond it.

Subscribe to the Best of Macworld Newsletter