5

A lot of password managers seems to promote client-side encryption as a key feature of their service. For example : LastPass, Firefox Sync, PasswordBox, etc...

They all say something like

Even we don't know your master password and cannot decrypt your data, hence it is more secure.

Making the user think that it protects him against the password manager he is using.

But, in reality, they control the code that does the encryption on the client side and can change it whenever they want to instead do the encryption on the server and you would not notice anything.

So, does it add any security?

Improve this question
2
  • If you don't trust the software then no?
    – RoraΖ
    Oct 23, 2014 at 16:06
  • If you run their software, they own your computer anyway!
    – paj28
    Oct 23, 2014 at 16:16

2 Answers 2

Reset to default
7

Client-side encryption does not protect against a malicious trusted application provider who decides to subvert their own system.

It does protect against attackers who breach the central store. Those people cannot decrypt without keys, and if the provider doesn't have the keys (the key feature (sic) described above), then the attacker can't steal those in the same manner. They'd have to compromise both the central store and the user endpoint(s), making a compromise of your data that much harder.

So does it really add security? Yes. Not for every use case, but for the use cases that realistically are a greater threat and a higher likelihood.

Improve this answer
2
  • 1
    Even if the encryption was done server side, they don't need to store the key unencrypted on the hard drive. They can keep an encrypted copy on the disk and a decrypted copy in memory (RAM). If the central store is compromised to a point where they can read your password in memory, they might also be able to alter the script that they send you on each page request to encrypt/decrypt your password. So it's game over again...
    – Gudradain
    Oct 23, 2014 at 17:17
  • The point is that, while they might store keys correctly or store it foolishly, if they don't have it you don't have to worry about how they handled it. (And, if they're sending you script rather than data upon requests, run. That's not likely.)
    – gowenfawr
    Oct 23, 2014 at 17:53
3

First, client-side encryption makes it hard for the company to sell or mine your data, at least as a business model.

What you say is true, you still need to verify the software does what it promises, and doesn't contain backdoors. Unfortunately the problem is still unsolved. Mostly because solving it doesn't help, too, as targeted attacks succeed through bugs in the software, which are expensive to find. But you can build a verification system that the software doesn't contain backdoors:

  1. verify the software does what it promises. This can be done through security reviews.
  2. ensure the code that has been reviewed matches the binary. This is done through deterministic builds.
  3. ensure the software comes to you unmodified. This is a software distribution problem and is more severe with auto-updates and web access, and less severe with installed software. Best is to require the software's hash to be released on public notary services like the bitcoin blockchain.

Also seee my answer on "Is it possible to design a system where the client doesn't have to trust the server?".

Also, client-side encryption means that you still need to trust the client, but don't have to trust the server. So if server and client are supplied by distinct vendors, you only have to trust the server.

Think who you add to your list of trusted companies. If you use a password manager that pastes the passwords into browser fields, the native browser client-side encryption is as good as that, as you already have to trust the browser.

Improve this answer

You must log in to answer this question.

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