LastPass Shared Folders are (maybe) unsafe*

June 18 2015

* unless you have an Enterprise account and use specific API calls.

LastPass, the popular online password manager has a fairly good reputation, in my view because it does many of the things that we need: usable, multi-device, client-side-encrypted storage of our secrets. Its single-user implementation is well understood and considered to be TNO.

The multi-user (Shared Folder) functionality though, doesn’t seem to have undergone the same level of scrutiny. The tl;dr here is that LastPass could, if they were so inclined, steal your Shared Folder secrets without much trouble.

How LastPass operates

The single-user story goes something like:

  • User signs up to LastPass
    • Generates an encryption key (KDF on their master password), login key (KDF on encryption key), and a RSA 2048-bit key-pair
    • Submits the login key, RSA public key, RSA private key (encrypted with encryption_key)
  • User logs into LastPass
    • Retrieves their KDF parameters from the server, derives their encryption & login keys from their master password
    • Fetches via authentication the encrypted account data
    • Decrypts the data using the encryption key (also decrypts his RSA private key), woohoo we have our passwords.

The multi-user story isn’t altogether different or surprising, at least initially.

  • User creates Shared Folder
    • Gives it a name
    • Generates a 256-bit AES key to be used for encrypting the contents of the Shared Folder (this key is shared between all members of the folder).
    • Encrypts the Shared Folder encryption key using RSA-OAEP of the user’s own key, and stores it

What happens next is concerning though,

  • User invites Colleague to Shared Folder
    • User enters Colleague’s email address into UI
    • User’s LastPass client visits the getpubkey API endpoint, to retrieve the public RSA key of Colleague
    • User’s LastPass client encrypts the Shared Folder encryption key with RSA-OAEP, using the result of getpubkey
    • User’s LastPass client submits a share API call to share the folder with Colleague’s user, submitting the encryption result from the previous step
    • Colleague receives invite via email, and LastPass adds the Shared Folder account to Colleague’s account.
    • Colleague can now decrypt the Shared Folder using using his RSA key.

At a glance, LastPass’ server does not see the Shared Folder encryption key during this process, but unfortunately its not guaranteed by design.

The Problem

I don’t see any reason the getpubkey call couldn’t just lie about Colleague’s RSA key - it is ripe for backdooring. Imagine that @joesiegrist was abducted by criminals and forced to implement server logic such that:

  • getpubkey backdoor activates on the next time a user is invited to the Shared Folder and reports an RSA key owned by the criminals
  • User unknowingly encrypts the Shared Folder data using the criminals’ RSA key and sends it to LastPass via share API
  • LastPass server decrypts the Shared Folder, records the data
  • LastPass re-encrypts the Shared Folder encryption key with Colleague’s real RSA key, and invites as normal.

So what’s happened here is a switcharoo on the Colleague’s RSA key, causing an unauthorized party to have access to the encrypted Shared Folder data. This is totally undetectable to the User using the normal LastPass UI - the RSA public key of the invitee is never visually represented.

I suppose you could make a manual request to getpubkey to check for backdoors before you invite anyone (after getting Colleague to extract his RSA key, that is - maybe I missed something obvious but I ended up recompiling lastpass-cli to dump the decrypted RSA key for me).

This makes me sad. Its understandable that LastPass wants to give your grandparents the ability to use their product without some ridiculous web-of-trust or key-exchange solution, but its less than ideal for an organisation concerned with security.

Fixing the problem

What I would like is the ability to perform some kind of verification, even if it is not mandatory in the UI. The web is real-time these days, there’s an opportunity to do OTR-style verification, or myriad other solutions that are improvements on “blindly trust this key”.

Interestingly, the enterprise edition of LastPass appears to have an API that allows you to share a folder with a user directly, encrypting the Shared Folder encryption key with an arbitrary RSA key of your choosing. I don’t have an Enterprise account though, so I’m not sure if this is actually the case.

Hopefully though, this indicates that LastPass are aware that the current system kind of sucks, and perhaps that their customers want something better.

I’m hesitant to recommend LastPass in some cases because of how Shared Folders work, only because of the lack of key verification in the standard UI. I’ll continue to use it though, even after the most recent hack, in absence of anything better.