Should you be concerned about LastPass uploading your passwords to its server?

Posted on by Wladimir Palant

TL;DR: Yes, very much.

The issue

I’ve written a number of blog posts on LastPass security issues already. The latest one so far looked into the way the LastPass data is encrypted before it is transmitted to the server. The thing is: when your password manager uploads all data to its server backend, you normally want to be very certain that the data visible to the server is useless both to attackers who manage to compromise the server and company employees running that server. Early last year I reported a number of issues that allowed subverting LastPass encryption with comparably little effort. The most severe issues have been addressed, so all should be good now?

Sadly, no. It is absolutely possible for a password manager to use a server for some functionality while not trusting it. However, LastPass has been designed in a way that makes taking this route very difficult. In particular, the decision to fall back to server-provided pages for parts of the LastPass browser extension functionality is highly problematic. For example, whenever you access Account Settings you leave the trusted browser extension and access a web interface presented to you by the LastPass server, something that the extension tries to hide from you. Some other extension functionality is implemented similarly.

The glaring hole

So back in November I discovered an API meant to accommodate this context switch from the extension to a web application and make it transparent to the user. Not sure how I managed to overlook it on my previous strolls through the LastPass codebase but the getdata and keyplug2web API calls are quite something. The response to these calls contains your local encryption key, the one which could be used to decrypt all your server-side passwords.

There has been a number of reports in the past about that API being accessible by random websites. I particularly liked this security issue uncovered by Tavis Ormandy which exploited an undeclared variable to trick LastPass into loosening up its API restrictions. Luckily, all of these issues have been addressed and by now it seems that only and domains can trigger these calls.

Oh, but the chances of some page within or domain to be vulnerable aren’t exactly low! Somebody thought of that, so there is an additional security measure. The extension will normally ignore any getdata or keyplug2web calls, only producing a response once after this feature is unlocked. And it is unlocked on explicit user actions such as opening Account Preferences. This limits the danger considerably.

Except that the action isn’t always triggered by the user. There is a “breach notification” feature where the LastPass server will send notifications with arbitrary text and link to the user. If the user clicks the link here, the keyplug2web API will be unlocked and the page will get access to all of the user’s passwords.

The attack

LastPass is run by LogMeIn, Inc. which is based in United States. So let’s say the NSA knocks on their door: “Hey, we need your data on XYZ so we can check their terrorism connections!” As we know by now, NSA does these things and it happens to random people as well, despite not having any ties to terrorism. LastPass data on the server is worthless on its own, but NSA might be able to pressure the company into sending a breach notification to this user. It’s not hard to choose a message in such a way that the user will be compelled to click the link, e.g. “IMPORTANT: Your Google account might be compromised. Click to learn more.” Once they click it’s all over, my proof-of-concept successfully downloaded all the data and decrypted it with the key provided. The page can present the user with an “All good, we checked it and your account isn’t affected” message while the NSA walks away with the data.

The other scenario is of course a rogue company employee doing the same on their own. Here LastPass claims that there are internal processes to prevent employees from abusing their power in such a way. It’s striking however how their response mentions “a single person within development” — does it include server administrators or do we have to trust those? And what about two rogue employees? In the end, we have to take their word on their ability to prevent an inside job.

The fix

I reported this issue via Bugcrowd on November 22, 2018. As of LastPass (released on February 28, 2019) this issue is considered resolved. The way I read the change, the LastPass server is still able to send users breach notifications with text and image that it can choose freely. Clicking the button (button text determined by the server) will still give the server access to all your data. Now there is additional text however saying: “LastPass has detected that you have used the password for this login on other sites, too. We recommend going to your account settings for this site, and creating a new password. Use LastPass to generate a unique, strong password for this account. You can then save the changes on the site, and to LastPass.” Ok, I guess this limits the options for social engineering slightly…

No changes to any of the other actions which will provide the server with the key to decrypt your data:

  • Opening Account Settings, Security Challenge, History, Bookmarklets, Credit Monitoring
  • Linking to a personal account
  • Adding an identity
  • Importing data if the binary component isn’t installed
  • Printing all sites

Some of these actions will prompt you to re-enter your master password. That’s merely security theater however, you can check that they have g_local_key global variable set already which is all they need to decrypt your data.

One more comment on the import functionality: supposedly, a binary component is required to read a file. If the binary component isn’t installed, LastPass will fall back to uploading your file to the server. The developers apparently missed that the API to make this work locally has been part of any browser released since 2012 (yes, that’s seven years ago).


I wrote the original version of this Stack Exchange answer in September 2016. Back then it already pointed out that mixing trusted extension user interface with web applications is a dangerous design choice. It makes it hard to secure the communication channels, something that LastPass has been struggling with a lot. But beyond that, there is also lots of implicit trust in the server’s integrity here. While LastPass developers might be inclined to trust their servers, users have no reason for that. The keys to all their online identities are data that’s too sensitive to entrust any company with it.

LastPass has always been stressing that they cannot access your passwords, so keeping them on their servers is safe. This statement has been proven wrong several times already, and the improvements so far aren’t substantial enough to make it right. LastPass design offers too many loopholes which could be exploited by a malicious server. So far they didn’t make a serious effort to make the extension’s user interface self-contained, meaning that they keep asking you to trust their web server whenever you use LastPass.



  1. Me

    How about bitwarden?

    Reply from Wladimir Palant:

    Unfortunately, I don’t have time to check all password managers, there are simply too many. I looked at Bitwarden briefly a few months ago, and my conclusions were:

    On a first glance, I’ve certainly seen worse codebases, but it isn’t flawless either. Custom URL query parsing, domain checks via substring search on the host name without validating position – a security-conscious codebase usually doesn’t do that. Whether there are actual security issues I cannot tell, that would require far more effort given the size of their codebase. And they are only running a Vulnerability Disclosure Program that won’t pay for the findings.

    In fact, there is one place that looks like a tiny and completely unnecessary security issue. Verifying that it actually is one would take too much time however, not worth it.

  2. Me

    “Too many”, hmm, are there other which are open source? (that’s why I asked about bitwarden, so something can be run off own infrastructure).

    Reply from Wladimir Palant:

    KeePass is another obvious alternative, but here you have to choose between security (no browser integration) and convenience (browser integration via hardly trustworthy third-party extensions).

    There is of course PfP: Pain-free Passwords which is open source, but being its developer I am obviously biased as far as its security goes. Also, the user interface needs polishing. And there is 1Password which has a good security story but it isn’t open source and has to be paid for.

  3. Kyle

    Bitwarden doesn’t do “Custom URL query parsing, domain checks via substring search on the host name without validating position” so I am unsure where you are seeing this. Bitwarden evaluates URLs via parsed hostname properties with built-in browser functions such as `new URL`.

    Bitwarden also pays for independent security audits of the codebase. More here:

    Reply from Wladimir Palant:

    Unfortunately, I didn’t make notes last time I looked into this – the issues simply weren’t serious enough for reporting. And I only looked at a small portion of the codebase, so when I look at it now it will probably be some different code paths. So the getDomain() function I see under is indeed using URL objects. It also knows that tld.js won’t handle IP addresses correctly, but it will only consider IPv4 addresses in dotted decimal notation and not IPv4 addresses in other notations or IPv6 addresses. All of that appears to be a minor risk but not an actual issue – assuming that URLs are already normalized when they get here (ok, let’s ignore the code prefixing URLs with http:// here).

    The code at the bottom of this function is quite problematic however. Rather than ignoring non-HTTP URLs, this function will pass them to tld.js. But tld.js isn’t aware that non-HTTP URLs can have different semantics, so it will happily return “” when it is fed something like “data://,asdf/”. Oops, I think that one might even be exploitable…

    I think I’m going to stop here. This needs a structured effort, not spending ten minutes every now and then. As I said, the codebase isn’t bad. But there are obvious issues that shouldn’t have been there. As always, spotting the issues is the easy part – proving that they are exploitable is far harder. I’m not going to spend time on that right now, so let’s just file these under “minor quality issues” rather than “security problems.”

  4. Jonathan

    So can you name any password manager that you feel is above average (besides your own PfP)? I’ve used LasPass for a couple of years and generally have been happy with it though the thought of storing my passwords somewhere else still concerns me.

    Reply from Wladimir Palant:

    Yes, I’m usually recommending 1Password. While I haven’t done a thorough review there, there were no issues sticking out – which is already a lot better than everybody else. Also, their whitepaper is really good, somebody put some considerable thought into security here. Downside: there is no free plan, you have to pay for it.

  5. Chris

    What I recommend to all you "do-it-your-selfers" out there, is to setup PassBolt, an open source self-hosted password manager. It provides PGP Security and a browser extension to make life easier. So if steal toe comes and kicks your door in, demanding access to all your passwords, well you can "accidentally" loose the key to your account and boom nothing they can do!

    One last thought, considering that browsers these days are basically malware in a box that either through 3rd party agencies or the browser manufactures themselves collect and harvest your data one way or another without you knowing (unless you were one of those guys who actually read the entire legal doc that you clicked yes to). Does it really matter to securely store your keys anways? Your only really protecting from Sam and Sally from next door. If a government, Corporation, or any other person like myself really wants your passwords we/they will find a way to get them. Period!

    One other final thought... consider 2 factor authentication, encouraged by many companies to further secure your service but in fact the real reason is another way to validate that you are who you say you are. It might not be a 100% fool proof yet but your phone records can be pulled through phone api's. Your name will be on the number if you are a paying customer without any modern (transparent) way of removing your name from these lists and if there is its, very cryptic on how you unsubscribe from this. I've been dealing with ATT at the moment and Twillio and hoping to get some real answers on privacy that apparently is not being honored by ATT. Might be a good topic to write about if you are into writing on privacy and security!

    Reply from Wladimir Palant:

    Yes, PassBolt are the good ones. It has been a while since I communicated with them, but the security issue I reported got a top notch incident response. In general, they clearly understand the potential threats here and are planning their system accordingly.

    You are wrong about the browsers, it's really not that bad. You probably don't want to have the Sync functionality enabled but they won't steal your data.

    As to using phones for 2 factor authentication, I've written on that already. I plan to have a more technical article on hardware tokens eventually.

  6. vishwas anand

    Wonderful article. Even we were working on the similar issue. One way could be, instead of using Symmetric key (probably stored in the browser - hence not safe) to encrypt passwords before sending to LastPass server, they could have used Asymmetric crypto system. Solution similar to this can be very helpfull in this case : Notice the private key never leaves the mobile device and hence the client does not has to trust on LastPass browser client.

    Reply from Wladimir Palant:

    Quite frankly, this isn't an issue to be solved by cryptographic means. It doesn't matter what kind of key scheme is used, the LastPass website should never have to decrypt your passwords -- only the browser extension or app. If the LastPass website is decrypting passwords (and right now it's a required part of the whole concept) then it can always divert the information.

  7. Fedor Indutnyy

    As a shameless plug, I'd like to mention a password manager application that I've built due to having trust issues with current major players in the field. Here's the website: . The idea is that instead of generating the passwords randomly, they're derived from a master password and domain/login pair. In this way, only encrypted domains and logins have to be synchronized between devices, instead of entrusting some entity with storing the full password.

    Reply from Wladimir Palant:

    Given that my PfP: Pain-free Passwords does pretty much the same thing - yes, that's a shameless plug. ;-)

    I've seen your app, and it has one big issue: it runs on the web. So anybody using it has to trust you, starting with your ability to keep that server secure. For example, what if your computer gets infected with malware? And they need to trust you personally, that you never turn on them and serve up a slightly different version of that code -- something that they cannot realistically verify. Even if you have this integrity, what if the local authorities knock on your door tomorrow? And the same trust has to go towards Amazon who is your hosting provider.

    PfP also can be used on the web but there are warnings saying that it's only for trying out the functionality. If people need the web version, they can download it and run locally.

  8. Tony mac

    Apologies for the stupid question but is using keychain on mac to store your passwords a bad idea? Why would I pay for something that mac already does? Apart from storing the passwords on apple’s servers I guess but everything else should be as secure as can be?

    Reply from Wladimir Palant:

    To be honest, I have no idea. My understanding is that the keychain is well-protected so that malicious applications cannot steal the data easily -- that's a good thing. Also, from the info on the web it seems that Safari and Chrome support keychain natively, so you don't need to copy passwords around -- also good, probably also means that a password won't be filled in on a wrong website (phishing protection). But syncing passwords to Apple servers is something I would definitely be wary of, particularly since I know that Google and Mozilla didn't go out of their way to protect your data (the former doing considerably worse).

  9. Sascha Pfeiffer

    Looks like you did quite some research here. Im the main developer behind psono and it would be amazing if you could search a little bit around if you find something. Im always looking for ways to improve it, so even if you only have some additional security enforcements, then that would be much appreciated.

    Psono has similar to Lastpass a client side encryption (in addition its Open Source and you can host it yourself), yet it does not load any additional ressources as Lastpass (so at least this hole is covered).

    Reply from Wladimir Palant:

    Nice, haven't heard of that one yet. Will give it a try.

  10. Jeffrey Goldberg

    Disclosure: I am the Chief Defender Against the Dark Arts at 1Password.

    One of our users asked us whether 1Password suffers from the same problems. I've written an answer in which I explain that we don't. We've worked hard to build 1Password so that we can acquire as little information about our uses as possible.

    The one place where some of the criticisms you list here (partially) apply to us is with our use of our web client within some of our native clients. I discuss the problem in the forum post I linked to, and it is also discussed in our security white paper. (The issue does not apply to our browser extension, so technically I could have said that we aren't exposed to what you describe, but that would have been misleading.)

    Reply from Wladimir Palant:

    Thank you for sharing this. I've mostly looked at the browser extension, wasn't aware of the issue with the native client.

  11. Mark Entingh

    Not only is the security questionable, but LastPass JavaScript code is very bulky and slow and can potentially boggle down your web browser on text field heavy web pages. This is due to LastPass checking every single field on the page against their internal database to see if it can auto-fill the form. There are options in LastPass to disable this, but in my experience, even after disabling it, LastPass STILL runs all the JavaScript that checks every single field on a web page against their internal database for form auto-filling, even if it doesn't actually fill the form.

  12. Tyler L

    Any thoughts on +

    Reply from Wladimir Palant:

    Sorry, no. I've seen this in principle but properly evaluating this solution would require considerable time (already because the browser extension isn't self-contained). And a command line password manager is a niche product, even if usability is improved by a third-party solution.

  13. Leon Moonen

    In response to Tony mac's question above: do a search for the "KeySteal" vulnerability discovered by Linus Henze, that allows an attacker to read your keychain if they can execute code under your account. As far as I know, it has not been closed at the time of writing (April 5, 2019). An example article describing it is here:


Enter your comment below.

Only if you want to be notified about my reply.

You can use Markdown syntax here.

By submitting your comment, you agree to your comment being published here under the terms of the Creative Commons Attribution-ShareAlike 4.0 International License.