Disclaimer: I created PfP: Pain-free Passwords as a hobby, it could be considered a LastPass competitor in the widest sense. I am genuinely interested in the security of password managers which is the reason both for my own password manager and for this blog post on LastPass shortcomings.
TL;DR: LastPass fanboys often claim that a breach of the LastPass server isn’t a big deal because all data is encrypted. As I show below, that’s not actually the case and somebody able to compromise the LastPass server will likely gain access to the decrypted data as well.
A while back I stated in an analysis of the LastPass security architecture:
So much for the general architecture, it has its weak spots but all in all it is pretty solid and your passwords are unlikely to be compromised at this level.
That was really stupid of me, I couldn’t have been more wrong. Turned out, I relied too much on the wishful thinking dominating LastPass documentation. January this year I took a closer look at the LastPass client/server interaction and found a number of unpleasant surprises. Some of the issues went very deep and it took LastPass a while to get them fixed, which is why I am writing about this only now. A bunch of less critical issues remain unresolved as of this writing, so that I cannot disclose their details yet.
Cracking the encryption
In 2015, LastPass suffered a security breach. The attackers were able to extract some data from the server yet LastPass was confident:
We are confident that our encryption measures are sufficient to protect the vast majority of users. LastPass strengthens the authentication hash with a random salt and 100,000 rounds of server-side PBKDF2-SHA256, in addition to the rounds performed client-side. This additional strengthening makes it difficult to attack the stolen hashes with any significant speed.
What this means: anybody who gets access to your LastPass data on the server will have to guess your master password. The master password isn’t merely necessary to authenticate against your LastPass account, it also allows encrypting your data locally before sending it to the server. The encryption key here is derived from the master password, and neither is known to the LastPass server. So attackers who managed to compromise this server will have to guess your master password. And LastPass uses PBKDF2 algorithm with a high number of iterations (LastPass prefers calling them “rounds”) to slow down verifying guesses. For each guess one has to derive the local encryption key with 5,000 PBKDF2 iterations, hash it, then apply another 100,000 PBKDF2 iterations which are normally added by the LastPass server. Only then can the result be compared to the authentication hash stored on the server.
So far all good: 100,000 PBKDF2 iterations should be ok, and it is in fact the number used by the competitor 1Password. But that protection only works if the attackers are stupid enough to verify their master password guesses via the authentication hash. As mentioned above, the local encryption key is derived from your master password with merely 5,000 PBKDF2 iterations. And it is used to encrypt various pieces of data: passwords, private RSA keys, OTPs etc. The LastPass server stores these encrypted pieces of data without any additional protection. So a clever attacker would guess your master password by deriving the local encryption key from a guess and trying to decrypt some data. Worked? Great, the guess is correct. Didn’t work? Try another guess. This approach speeds up guessing master passwords by factor 21.
So, what kind of protection do 5,000 PBKDF2 iterations offer? Judging by these numbers, a single GeForce GTX 1080 Ti graphics card (cost factor: less than $1000) can be used to test 346,000 guesses per second. That’s enough to go through the database with over a billion passwords known from various website leaks in barely more than one hour. And even if you don’t use any of the common passwords, it is estimated that the average password strength is around 40 bits. So on average an attacker would need to try out half of 240 passwords before hitting the right one, this can be achieved in roughly 18 days. Depending on who you are, spending that much time (or adding more graphics cards) might be worth it. Of course, more typical approach would be for the attackers to test guesses on all accounts in parallel, so that the accounts with weaker passwords would be compromised first.
Statement from LastPass:
We have increased the number of PBKDF2 iterations we use to generate the vault encryption key to 100,100. The default for new users was changed in February 2018 and we are in the process of automatically migrating all existing LastPass users to the new default. We continue to recommend that users do not reuse their master password anywhere and follow our guidance to use a strong master password that is going to be difficult to brute-force.
Extracting data from the LastPass server
Somebody extracting data from the LastPass server sounds too far fetched? This turned out easier than I expected. When I tried to understand the LastPas login sequence, I noticed the script
https://lastpass.com/newvault/websiteBackgroundScript.php being loaded. That script contained some data on the logged in user’s account, in particular the user name and a piece of encrypted data (private RSA key). Any website could load that script, only protection in place was based on the
Referer header which was trivial to circumvent. So when you visited any website, that website could get enough data on your LastPass account to start guessing your master password (only weak client-side protection applied here of course). And as if that wasn’t enough, the script also contained a valid CSRF token, which allowed this website to change your account settings for example. Ouch…
To me, the most surprising thing about this vulnerability is that no security researcher found it so far. Maybe nobody expected that a script request receiving a CSRF token doesn’t actually validate this token? Or have they been confused by the inept protection used here? Beats me. Either way, I’d consider the likeliness of some blackhat having discovered this vulnerability independently rather high. It’s up to LastPass to check whether it was being exploited already, this is an attack that would leave traces in their logs.
Statement from LastPass:
The script can now only be loaded when supplying a valid CSRF token, so 3rd-parties cannot gain access to the data. We also removed the RSA sharing keys from the scripts generated output.
The “encrypted vault” myth
LastPass consistently calls its data storage the “encrypted vault.” Most people assume, like I did originally myself, that the server stores your data as an AES-encrypted blob. A look at https://lastpass.com/getaccts.php output (you have to be logged in to see it) quickly proves this assumption to be incorrect however. While some data pieces like account names or passwords are indeed encrypted, others like the corresponding URL are merely hex encoded. This 2015 presentation already pointed out that the incomplete encryption is a weakness (page 66 and the following ones). While LastPass decided to encrypt more data since then, they still don’t encrypt everything.
The same presentation points out that using ECB as block cipher mode for encryption is a bad idea. One issue in particular is that while passwords are encrypted, with ECB it is still possible to tell which of them are identical. LastPass mostly migrated to CBC since that publication and a look at
getaccts.php shouldn’t show more than a few pieces of ECB-encrypted data (you can tell them apart because ECB is encoded as a single base64 blob like
dGVzdHRlc3R0ZXN0dGVzdA== whereas CBC is two base64 blobs starting with an exclamation mark like
!dGVzdHRlc3R0ZXN0dGVzdA==|dGVzdHRlc3R0ZXN0dGVzdA==). It’s remarkable that ECB is still used for some (albeit less critical) data however. Also, encryption of older credentials isn’t being “upgraded” it seems, if they were encrypted with AES-ECB originally they stay this way.
I wonder whether the authors of this presentation got their security bug bounty retroactively now that LastPass has a bug bounty program. They uncovered some important flaws there, many of which still exist to some degree. This work deserves to be rewarded.
Statement from LastPass:
The fix for this issue is being deployed as part of the migration to the higher iteration count in the earlier mentioned report.
A few words on backdoors
People losing access to their accounts is apparently an issue with LastPass, which is why they have been adding backdoors. These backdoors go under the name “One-Time Passwords” (OTPs) and can be created on demand. Good news: LastPass doesn’t know your OTPs, they are encrypted on the server side. So far all fine, as long as you keep the OTPs you created in a safe place.
There is a catch however: one OTP is being created implicitly by the LastPass extension to aid account recovery. This OTP is stored on your computer and retrieved by the LastPass website when you ask for account recovery. This means however that whenever LastPass needs to access your data (e.g. because US authorities requested it), they can always instruct their website to silently ask LastPass extension for that OTP and you won’t even notice.
Another consequence here: anybody with access to both your device and your email can gain access to your LastPass account. This is a known issue:
It is important to note that if an attacker is able to obtain your locally stored OTP (and decrypt it while on your pc) and gain access to your email account, they can compromise your data if this option is turned on. We feel this threat is low enough that we recommend the average user not to disable this setting.
I disagree on the assessment that the threat here is low. Many people had their co-workers play a prank on them because they left their computer unlocked. Next time one these co-workers might not send a mail in your name but rather use account recovery to gain access to your LastPass account and change your master password.
Statement from LastPass:
This is an optional feature that enables account recovery in case of a forgotten master password. After reviewing the bug report, we’ve added further security checks to prevent silent scripted attacks.
As this high-level overview demonstrates: if the LastPass server is compromised, you cannot expect your data to stay safe. While in theory you shouldn’t have to worry about the integrity of the LastPass server, in practice I found a number of architectural flaws that allow a compromised server to gain access to your data. Some of these flaws have been fixed but more exist. One of the more obvious flaws is the Account Settings dialog that belongs to the lastpass.com website even if you are using the extension. That’s something to keep in mind whenever that dialog asks you for your master password: there is no way to know that your master password won’t be sent to the server without applying PBKDF2 protection to it first. In the end, the LastPass extension depends on the server in many non-obvious ways, too many for it to stay secure in case of a server compromise.
Statement from LastPass:
We greatly appreciate Wladimir’s responsible disclosure and for working with our team to ensure the right fixes are put in place, making LastPass stronger for our users. As stated in our blog post, we’re in the process of addressing each report, and are rolling out fixes to all LastPass users. We’re in the business of password management; security is always our top priority. We welcome and incentivize contributions from the security research community through our bug bounty program because we value their cyber security knowledge. With their help, we’ve put LastPass to the test and made it more resilient in the process.
I found your posts about password managers and their security very interresting. Have you already “analyzed” the new Mozilla project (https://lockbox.firefox.com/) ? … It would be very usefull having your opinion about it :)
Thanks in advance ;)
Yes, I looked into it a bit and concluded that its dependency on Firefox Accounts is its weakest spot right now. See https://palant.de/2018/03/13/can-chrome-sync-or-firefox-sync-be-trusted-with-sensitive-data, it’s also an issue for Lockbox.
Reading your posts, it really seems like LastPass has a huge problem. I’ve been wondering whether this is a general problem with cloud-base password managers, so I’ve been looking into a password manager called Myki which basically has the passwords saved on your phone and sends them to your laptop on demand when approved on the phone. Quite interesting, what do you think about it?
Unfortunately, it’s impossible to say. Cloud-based password managers aren’t such a bad idea, it is absolutely possible to get them secure. On the other hand, while having your passwords stored locally (or on a phone, doesn’t make a big difference) is theoretically the more secure option, features added for convenience often punch holes into these solutions. In the end, it all boils down to whether the people building the product are serious about security and know what they are doing. So I am quite confident about 1Password despite it being a cloud-based solution. I’m also fairly confident about my own PfP extension. Other password managers that I looked at usually weren’t totally bad but had their weak spots. For example, Keepass is a stand-alone Windows application and provides a small attack surface. Yet it used a weak key derivation until recently and still supports it for backwards compatibility. Also, there is a number of browser extensions providing some comfort and their security level varies a lot.
I use Myki as my daily driver. The product is great and the support team is amazing. Apparently the founding team were lastpass users and developed Myki to address the issues associated with cloud storage and master passwords. I give it a 9/10 (not 10 because i’m still waiting for them to add support for multiple smartphones at the same time. Today you can have as many computers paired to your smartphone as you like but there is a limitation on the number of smartphones. The team assured me that they are working on the feature and will release it this summer).
Hi, very interesting, I have a question about the derived encryption key, They mention that the master password (indeed the derived key) does not leave the client computer, is this a contractual deal or is there a technical gate which prevents this behaviour. Client side encryption is really a good feature but if the key remains in lastpass domain and js context, how can we be sure that the key is not sent to LastPass ?
Has LastPass corrected the issues you identified, as it claimed it was working on in its last comment? Have you discovered any new issues with LastPass? Better yet, are there other password managers you feel are more secure (if not 100%)?
It corrected them to some degree. But these issues run deep, the system just wasn’t built to protect your data against a compromised server. The whole thing with local encryption is more of a PR stunt, not really a main design goal.
In fact, I discovered another issue allowing LastPass to decrypt your data easily, e.g. if authorities ask for it. Submitted end of November 2018, the issue has been assigned low priority. I’ll write about it once it is fixed, but I don’t expect that to happen soon.
While I looked into a bunch of password managers, it’s by far not all of them. From the ones I’ve seen, only 1Password had a convincing security approach, they seem to understand the threat models and design their product accordingly. Mind you, I didn’t do an in-depth review, so there might still be security issues hidden there. Of course, personally I prefer using PfP: Pain-free Passwords but this one I wrote myself and it’s probably not everybody’s thing.
I know this is an old posting, but I have a question about the numbers given for testing passwords against a hash using 5,000 PBKDF2 iterations.
You claim a 1080Ti can do 346000 guesses/s
The page you're referring to says 1730.9 kH/s which given 5000 iterations gives me 1730.9*10^3/5000=346.18 which is a factor 1000 less than what you state.
Am I missing something here?
Yes, you are missing something. The benchmark numbers are for 1000 iterations, not for one.
This was really non-obvious in older hashcat versions, one had to look up the default settings in the source code. New hashcat versions will show the number of iterations as well.
I think patrik is correct. He already multiplied the hash rate by 1000 (10^3)
Unless I'm missing something and one Hash actually means 1000 Iterations? wut?
Yes, one hash in this hashcat setting uses 1000 iterations, so he would have to multiply by 1000 twice to account for both kH and the number of iterations.