18

Web application may encrypt all user data at client side to convince users that it can't decrypt them.

When user enters password, it's used to encrypt data in browser and then it's sent to server in encrypted state. Server doesn't know password, encryption key and thus can't decrypt it.

But most of the users aren't able to review code used for encryption. All they can do is to trust it. Client side encryption may give feeling of control but:

  • Server can send one encryption code to one user and another one to the other
  • Government organization may urge server-side company so that it will disable encryption for certain users

So is there any benefit in client side encryption from user point of view?

Andrei Botalov
  • 5,267
  • 10
  • 45
  • 73
  • @AndreyBotalov - the reason to do client side encryption is to secure the data. If you send it in plain text it can be read if the packets are intercepted. –  Jul 09 '12 at 12:23
  • 4
    @ChrisF Preventing eavesdroppers from traffic interception is done using Transport Level Security. Client side encryption can't help in it as eavesdropper can modify code that does encryption. – Andrei Botalov Jul 09 '12 at 12:28
  • @AndreyBotalov eavesdropping doesn't necessarily include local code alterations, that's a much more sophisticated and personal attack vs just sniffing packets – Ben Brocka Jul 09 '12 at 13:15
  • 1
    @BenBrocka In any case Javascript can't be used instead of TLS for encryption as JS code isn't protected from changing at transport level. I asked whether users think that client side encryption is better than server side. – Andrei Botalov Jul 09 '12 at 13:21
  • 4
    @Andrey I am pretty sure that your question can be described with this sentence: _"**web-applications** using **javascript** to perform **encryption** in **web-browsers** for added **trust**"_, so I added the **javascript** and **web-browsers** tags. If by chance I misinterpreted the scope of your question, please remove these tags. – curiousguy Jul 11 '12 at 03:05

5 Answers5

12

You are correct. Given your goals, client-side encryption probably doesn't make a lot of sense. It is not that it is worthless, just that there are some significant pitfalls and the value is limited, so your time would probably be better spent on other measures. A classic technical reference on this topic is Javascript Cryptography Considered Harmful.

If you're thinking that using client-side cryptography might help perception, even if it doesn't actually improve real security, I don't think that's a very promising angle, either. The average user is going to have no clue what the phrase "client-side cryptography" means and so I don't think they're going to associate it with warm fuzzy feelings.

I think you are better off taking standard steps to build trust with your users and to improve how you protect your users' data. Have you moved to sitewide HTTPS? Do you have a strong, customer-friendly privacy policy? Are you focused on serving your customers well and making them passionate about your site?

D.W.
  • 98,420
  • 30
  • 267
  • 572
  • Is it better to send your password to a website in plain text (even if over HTTPS)? – steshaw Aug 05 '14 at 01:57
  • 4
    @steshaw, the question is comparing client-side encryption to server-side encryption (not client-side encryption to nothing). So, the alternative is not sending the password in plaintext; the alternative is sending it over HTTPS. As my answer says, client-side encryption probably does not add enough over HTTPS to be worthwhile, for most web sites. – D.W. Aug 12 '14 at 18:39
3

As other users have mentioned a lot of the discussion around this is going to be more under the umbrella of IT Security. However I think there is a UX perspective on this (or at least the beginnings of a discussion), which I'll try to detail below.

You've mentioned the answer in the question itself:

Client side encryption may give feeling of control

As you've mentioned, neither client-side nor server-side encryption is foolproof in terms of security, so there's nothing to choose between them, right?

Well, there is - it's about perception. If your users perceive that their data is being treated in a secure manner, then they are likely to be more happy regardless of whether or not this is actually the case.

Admittedly it's important not to lie to your users about the risks, but since only a small minority of users in most applications are likely to care, you can discuss the nitty-gritty details of your security solution somewhere where it won't get in the way of disinterested users.

Given this, the solution that I would suggest would be to perform client-side encryption to give your users a feeling of control, and then have some progressive disclosure of your security mechanism, its details and exactly how secure it is, for the users that do care.

EDIT: I'm aware that this position may have ethical implications depending on what you feel your users need to see. From a dispassionate perspective, however, perception is king.

  • 3
    Just keep in mind that whatever password hashing you do on the client side results in the hash being the password anyway. i.e. if you do `hash("password") = "1a2b3c4d5e6f..."` on the client side, the password (as far as an attacker is concerned) is now `"1a2b3c4d5e6f..."`. – Polynomial Jul 10 '12 at 10:31
0

You could write an offline-mode client for the browser, like the Google Mail offline client for Google Chrome (it's a thick client running inside a thin client!).

That way the JS code:

  • is running in the browser, with the usual sandboxing (cannot mess with user files, etc.)
  • but it is only downloaded once, and cannot be changed per user/per connexion

To make sure every user gets the same package, its fingerprint needs to be published in a public repository, preferably replicated on many sites, and checked automatically after download, before installation.

Warning: this is merely the suggestion of a hint of an idea. I have not studied the "offline reader" security model.

Note: Firefox extensions have full access to everything in the browser (they are not sandboxed), so they would not be a good fit here, as they imply full user trust which is not a given (instead of the limited "I trust you with these informations, I trust you with follow your privacy policy").

curiousguy
  • 5,028
  • 3
  • 25
  • 27
0

Doing the encryption in JavaScript on the client side has the advantages of open source security - you aren't hiding away some ROT-13 "encryption" scheme, so users trust you more. This also holds if someone breaks into your server and replaces said JavaScript with nefarious code.

Most users won't read the JavaScript or compare it to cached versions, and some users will get their secrets stolen if there is a breach. But you are much less likely to be that company that unknowingly leaked all the users' secrets for the past five years.

Fax
  • 175
  • 6
-4

Everything that is not encrypted on the client side, is basically open to everyone. If you want to have a minimum of privacy, there is no way around client side encryption.

hw75
  • 11
  • There is such thing as TLS – Andrei Botalov Jun 01 '13 at 11:11
  • 2
    This should perhaps explain **why**. – Jeff Ferland Jun 01 '13 at 14:30
  • 2
    Maybe hw75's argument is that TLS/SSL/HTTPS _does_ encrypt on the client side. – steshaw Aug 05 '14 at 01:59
  • I don't understand the downvotes on this. TLS protects you from rogue middle-boxes leading to the cloud provider only. TLS is plaintext on both ends of it, and if one end is inside the cloud provider, then it's not open to "everyone", but it is surely readily compromised by the service provider. It is a development effort for the cloud provider to break your crypto, but governments have the procedure down. First, your server cert is on the server machine. – Rob Aug 30 '18 at 15:35
  • He's making an obvious observation about end-to-end encryption, that almost everybody running servers in the cloud seems to have forgotten. – Rob Aug 30 '18 at 15:39