LastPass’s local-only decryption only technically so

LastPass is a password manager and service that promises local-only password decryption: "Your key never leaves your device, and is never shared with LastPass." (, 2015-06-15.) That claim sounds good, and it's technically true under normal usage, but they completely fail to ensure that it *can't* happen -- that is, even under an attack scenario.

The basic premise is pretty sound: Your password vault is kept locally using a browser extension, encrypted by a key derived from an iterated hash of your master password. That master password is not shared with LastPass in the normal course of events1, but the encrypted vault is synced with LastPass's site and then to your other browsers. You use the extension's Local Vault to manage your passwords, and it All seems pretty legit -- they don't see your unencrypted passwords. (I'm going to ignore the password sharing feature for the purposes of this post -- it can't be made secure, so I'm not complaining.)

But then there's the Online Vault.

The Online Vault is very similar to the Local Vault, except it is accessed over HTTPS on instead of being hosted locally as a browser extension. Various actions will take you to the Online Vault (presumably where the browser extension does not have feature parity), and rather unpredictably so. Your passwords are all available in this page because the browser extension recognizes the domain and/or cert and conveys key material of some sort into the page. The password data is decrypted locally, but the scripts running in the page are loaded across the web.

This is clearly a problem. If LastPass's site is compromised in the wrong way, an attacker could then load malicious scripts into the Online Vault, and when the browser extension hands over the derived keys, the attack code would decrypt the data and exfiltrate it to Siberia or god knows where. I don't care how careful they are: This is very close to violating their "only decrypted locally" claims, in spirit though not in letter.

I tried to contact LastPass support about this. They didn't see the problem, misunderstanding my point several times. I don't think they're taking this seriously at all. I also asked if there was a way to prevent the browser extension from extending trust to the Online Vault, and they said there was not. So much for that.

These are my takeaways:

  • LastPass arrogantly assumes their site cannot be compromised
  • You should probably set your browser to block the Online Vault from loading
  • Firefox's password manager is still the most secure option I've seen for browser-integrated password management

1. You give it to them to log in on the website, and presumably the browser extension does so in some fashion as well. I believe both of these use a derived key, but in the former case that is done in JS served from, which is not great.

Update 2018-04-30: Or rather, no update. Two and a half years later, their Content-Security-Policy still includes script-src 'self' 'unsafe-inline' 'unsafe-eval' 'self'. Given how vulnerable their browser extension code is (examples involving password disclosure or remote code execution: 1, 2, 3) I can only imagine how bad their server code must be.

Responses: 2 so far Feed icon

  1. Zusukar says:

    If you have a MitM that can impersonate a valid TLS connection to LastPass your attack surface is larger than a javascript file from LastPass. The attacker could instead send an update to the plug-in directly and not care about the Online Vault. Firefox's password manager would be similarly compromised when it fills in the credentials on the MitM's TLS validated phishing site on the target domain.

    If you are concerned with LastPass's Online Vault you might consider using KeePass and a method to sync the KeePass database file.

    It will be nice if solutions like SQRL ( become common place as then we will only be giving out public keys and verifying them.

  2. Tim McCormack says:

    @Zusukar: My scenario does not require a MitM, just a reflected or stored XSS vulnerability on (Also note that their Content-Security-Policy header is woefully insufficient.)

    I haven't looked into alternatives, but should. At home I use Firefox's password manager, which is simple and pretty well-studied. Something not in-process with the browser would likely be more secure, though.

    And goodness yes, I would love to see a new auth standard take hold that does not involve passwords.

Commenting is not yet reimplemented after the Wordpress migration, sorry! For now, you can email me and I can manually add comments.