I'm trying to understand how LastPass can be secure if it allows sharing passwords with users who have not even created accounts yet.

Their FAQ says, "When you want to share data with someone else, you pull their public key and use that to encrypt the data." However, the forum thread "Password sharing: how is this done securely?" makes it clear that you can share a password with someone who doesn't have a LastPass account because "they will be given an opportunity to create an account."

How can this be secure? The insecure scenario I envision is:

  1. I indicate what password I want to share and what (future) user should receive it
  2. My LP client encrypts the data with a server-owned key and uploads it to the server
  3. The other user creates an account and an RSA key pair
  4. The server encrypts my password using the newly-created public key
  5. The other user's LP client downloads the encrypted data from the server
  6. The other user's LP client decrypts the data using the user's private key

In this scenario, the password is readable by people other than my intended recipient: the admins of the LP server can read it. If the server doesn't store it securely and if they suffer a security breach, even more people can read it. This seems like an edge case, but if the admins are willing to make my passwords available to themselves in this case, I imagine that they are willing to do so in other cases.

The admin on the forum thread linked above and those employees responding to my customer service inquiries either haven't understood the problem or are trying to brush off people who ask about this. (The forum thread is hard to believe because the admin does such a good job of avoiding the security concern.)

3 Answers 3


According to the linked forum thread, the target sharee is required to create an account before the password is "shared"...

The thread participants claim that no unencrypted shared password is stored on LP servers. Once the target sharee creates an account and supplies a public key, the target password would be encrypted with the target user's public key on your client side and uploaded to the LP database.

Thread Ref:

by jonat » Wed May 25, 2011 4:46 pm

If you read the user manual about sharing, it sends the recipient an 
email inviting them to open a LP account if they don't have one. As 
Israel says, nothing is actually shared until the account exists and 
the sharing accepted, by which time the keys are in place.
  • Thank you. Unfortunately, even if 'no unencrypted shared password is stored on LP servers', the password could be encrypted with the server's key (not the intended recipients'), which is not a desired practice. The design you describe of the password being encrypted 'on your client side' is the one that I want, but I can't find any assertion from official sources that that's what LP is doing. In other words, I still can't refute the model that I proposed in my OP. +1 for your help.
    – Jellicle
    Dec 13, 2017 at 1:47

As with any password management service, you basically have to trust that the developers/operators of the service correctly implemented everything. If they cut corners or made mistakes, well you're out of luck security wise.

I'm not entirely familiar with LastPass, but i imagine they store and manage account's public keys in order to maintain trust of those public keys. So I would think you trying to share a password results in the other user creating an account, then your LastPass instance pulls the key it was waiting for an encrypts the password.

But this might not be the case, as LastPass is fairly opaque in their methods and software. It boils down to if you believe LastPass as a company and technology is trustworthy. If they are, which is likely, then you have little to worry about.


Well, yeah. If the feature is that you can "send" a password to someone who does not yet have an account / public key, and you want it delivered as soon as they create an account, then yeah, it needs to be stored on the server in some way that the server can re-encrypt the data in the future for some key than doesn't exist yet.

The fact that they're refusing to give you a direct answer is bad customer service, but I can't imagine the feature works they way you describe, then I think it needs to work the way you describe. If you're uncomfortable with this, then wait until users have an account and a public key before sending them sensitive data.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .