PSA: LastPass Does Not Encrypt Everything In Your Vault

Written by concerned_lastpass_user | Published 2017/01/18
Tech Story Tags: security | passwords | lastpass | password-management | encryption

TLDRvia the TL;DR App

As a software engineer and long time LastPass user, I’ve always been an advocate of password managers. With data breaches becoming more and more common these days, it’s critical that we take steps to protect ourselves online. However, over the past year LastPass has made some decisions that have made me question their motives and ultimately has recently caused them to lose my business.

Last year LastPass introduced a new redesign of their vault in which they added nice pretty logos of all the sites in your vault.

The LastPass redesigned vault with site logos.

This got me wondering, if LastPass is encrypting all of my data before it goes to their servers (like they claim) how are they able to show these logos to me when rendering the vault webpage? I turned to my browser’s developer tools to find out.

Here is the data being sent to LastPass when I save a site in my vault for Google.com:

One of these is not like the other…

As we can see name, grouping (the folder), username, and password all contain AES encrypted data in the form of:

!initialization_vector|cipher_text

However, that URL property doesn’t look like an encrypted string to me.

Whenever I save a site on a different LastPass account for Google.com, we see this:

Url data is saved the same for every LastPass account.

As you can see, all accounts are saving the same unprotected, hexadecimal encoded string for Google.com:

68747470733a2f2f6163636f756e74732e676f6f676c652e636f6d2f536572766963654c6f67696e

Which when decoded is:

https://accounts.google.com/ServiceLogin

LastPass then uses this encoded string to render a logo for all sites in your vault for Google. I reached out to LastPass support inquiring about this and received the same canned response that’s repeated all over their website:

LastPass encrypts your Vault before it goes to the server using 256-bit AES encryption. Since the Vault is already encrypted before it leaves your computer and reaches the LastPass server, not even LastPass employees can see your sensitive data.

Read more here https://lastpass.com/support.php?cmd=showfaq&id=6926

This is concerning for a few reasons:

  1. LastPass claims that they are a “zero knowledge” platform and that no unencrypted, readable site data is ever sent to their servers. This is obviously not true. Hex strings are basically the same as plaintext in this case.
  2. LastPass could use this information to track what sites are in your vault, how often you visit them, how often you log into them, etc. I would encourage you to read their privacy policy for information on what they may share or sell to third parties. Having this type of data on millions of users would be extremely valuable.
  3. Worst of all, URLs can (and often do) contain sensitive data. For example, an HTTP basic auth URL might look like this: https://username:password@website.com. Or you might unknowingly store a URL that contains a password reset token in it (which isn’t hard to do with LastPass’s features that assist you in automatically onboarding new sites in your vault). It’s important that you audit your site’s URLs in LastPass for any such data.

Some people may not really care about this information being sent to LastPass unencrypted since their usernames and passwords are still protected properly (with exception to the case pointed out in #3 above), however, I think that LastPass is deceiving it’s users when they make the current claims that they do. Some users may be more conscience about their privacy and are unknowingly submitting their identifying private data to LastPass. Who knows what they are doing with the data that they have?

I’ve since moved to a more transparent, open source password manager that I can trust and I haven’t regretted it. Check out https://bitwarden.com for a comparable free alternative to LastPass.


Published by HackerNoon on 2017/01/18