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

TL;DR: Yes, very much.

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.


  • Me

    How about bitwarden?

    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.

  • 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).

    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.

  • 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:

    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.”

  • 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.

    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.

  • 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!

    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.

  • 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.

    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.

  • 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.

    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.

  • 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?

    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).

  • 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).

    Wladimir Palant

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

  • 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.)

    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.

  • 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.

  • Tyler L

    Any thoughts on +

    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.

  • 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:

  • Prashant

    A very insightful blog like always... Thanks you @Wladimir Palant. I've been reading you blog since quite some time and I really appreciate and enjoy your blog. Sir, I have lot of questions regarding password management. I've read all your article regarding LastPass and password managers. I am currently using Google Chrome to store most of my password. I use random and different passwords for all sites and use keepass to store sensitive logins like banking and Email logins for rest Chrome password manager. All passwords I use are generated by password generators having 20+ characters. Just like an average user I use Chrome as default browser, google as search engine, use an Android phone, google Photos to backup my photos, Drive for docs, so i have no right to wear a tin hat on my head lols (Although I have started to change my habits and try using duckduckgo and tor network as often as I can) So privacy wise at this point Google knows alot about me, so is it bad if they know login credentials ? They already have my history, bookmarks and cookies already. And i've read your blog about Google "passphrase" and use of SHA1, so that's more like a joke in the name of encryption, hence I don't use passphrase. Therefore it basically just boils down to if Google wants to use my data and i'll have to trust in their work ethics. But, isn't this trust factor issue with every company that provides an online password manager ?

    Secondly about security, regarding my devices I have no threat from anyone around me at home or at work that any one will sneak up on my laptop or mobile and steel my credentials, there is "0" risk of that, in my case. And when it comes to the installation of a malware on my device then the war is already lost isn't it ? If I already have a malware or a keylogger no password manager will save me IMHO.

    Next comes server side protection, now being a layman and having no knowledge of server security I can't comment anything. Just a gut feeling that Servers of Google (a company having infinite resource) might be better fortified then companies (comparatively very small than Google) like Lastpass or 1password or bitwarden. But again I am a layman so I might be horribly wrong.

    And lastly I fear that in case of a online password manager if there is a data leak and my login credentials are exposed (even if passwords are encrypted) it might expose me alot more for attacks like spear phishing. Where as in case of using Google Chrome password manager the attacker will have to go after specifically me in particular, and i am not in any sense a high value target so no one will do that..

    Sorry for such a long elaborate rant, can you clear my doubts ?? Also my apologize if my question seems dumb.... Thank you

    Wladimir Palant

    No, with online password managers you don't always have to trust the company. If a sane client-side encryption approach is used, the company really won't be able to access your passwords. As to work ethics, have a look at - do you want to bet on nobody at Google doing anything like this?

    You are correct, having malware on your device is the worst-case scenario that password managers cannot protect you against.

    As to Google servers being better protected - you are probably correct, even though people found really embarrassing security issues in Google servers as well. But the point is that you really shouldn't have to worry about this. Ideal scenario would be: even if somebody hacks the servers, this doesn't get them any closer to accessing the data. So you don't have to worry about hackers, rogue employees or companies with flexible ethics. Google is very far from that ideal scenario, 1Password is much closer though not without issues either, and LastPass is somewhere in between.

    If you are syncing your passwords to Google servers, then why would anybody have to single you out? Google servers are a high-value target, if these are compromised at some point then all people keeping their data there will be affected. Of course, if you only keep passwords locally then the chances of an attack are indeed far smaller.

  • Prashant

    Thank you sir for such a detailed answer. I have a quick follow up question, what are your thoughts on Bitwarden ? Can it be used and trusted ? I have heard good things about 1password, but its slightly expensive. I being a student, and not having lot of bucks, so would go for 1password only if there are no good free alternatives. I have tried Lastpass on and off and have mixed feelings about its clunky and sluggish UI, so in this match-up where would you put Bitwarden ???  I think, just by being Open source you don't become better or more secure compared to competitors who are closed source IMHO. It just mean more people have eyes on your code (and that can also become a negative thing). Open source is better only when capable people are actually looking and actively participating in bug reporting and threat analysis. BW has had "1" third party audit, But, is it good enough in your opinion ?? Thank you

    Wladimir Palant

    See my replies to comments #1 and #3 here, I don't currently have anything to add on Bitwarden.

  • Asgeir

    This was an insightful article. Thank you. I was just in the process of setting up LastPass on my devices upon reading this. I need to use both Mac, Windows and iOS, and decided a cross platform password manager was a better alternative than storing passwords in the browser/keychain on the different devices. I have been reading a bit, and understand that due to for example phishing security vulnerability, I probably shouldn´t use browser autofill at all. Even with e.g. 1password, it poses a risk using autofill in browser plugins?

    If this is the case, a cross platform synced desktop app is the way to go, copying the password into the browser each time. To my understanding I think your main concerns with LastPass lies with using the browser plugins?

    I would really like to save the monthly 5$ family plan fee for 1Password, but would be willing to pay it if browser plugin autofill is safe to use.

    To short it up, my two main questions are as follows: Is browser plugin autofill secure to use with 1Password? If no(ish) to the former, is Lastpass and 1Password equaly secure if used only as desktop apps, copying passwords from the app in to the web-browser manually?

    Wladimir Palant

    No, 1Password implemented the sensible solution - autofill isn't actually automatic, it's rather triggered by your action. When this is implemented correctly (in their case it is), there is no way to exploit it.

    The browser integration represents much of the attack surface of course. It can be done well to minimize the risk, it's just not how LastPass approached this. Stand-alone applications without browser integration have another issue: they are very inconvenient to use, so people will often install third-party solutions for convenience which again introduce risks. That's the case with the otherwise quite recommendable KeePass application.

    One remaining risk with stand-alone applications is still sync. Even if you do it manually by copying the database around, that database needs to be properly encrypted - what if you lose that USB stick? Unfortunately, even encrypted databases aren't always secure (see Recognizing basic security flaws in local password managers for an example). What I've seen from 1Password was sane however. Same goes for KeePass if the newer Argon2 key derivation is used (and don't bother with their two factor authentication plugins).

  • Asgeir

    Thank you for taking the time to answer me. I have now started to use 1Password, and a new question arises. The use of the online service. Is it just as safe for me to enter my master password on their online service via a browser as it is in the stand-alone app, or should I avoid using the online service?

    Wladimir Palant

    If you ask me, the online service is not to be trusted. If there is some fishy activity in the standalone app or browser extension, there is a good chance that somebody will notice it. With the website, you are on your own and you don't stand a chance.

    Mind you, I might be overly paranoid here. As long as you aren't a high profile target this most likely won't be an issue. But personally I prefer not to take any chances.

  • David

    I recommended you for the next Bitwarden audit ;)

    Wladimir Palant

    Thank you :-)

  • David

    Wladimir, please join the Open Source Security Summit today Dec 10 at 4pm-6pm CEST:

    Wladimir Palant

    You posted that after the event already ended. Either way, I had other obligations at the time.

  • David

    Ignore my previous message, it's already ended :)

  • Håkan Save Hansson

    Great article. Thanks!