12

I just read about the Stanford Javascript Crypto Library (jsfiddle example) which supports SHA256, AES, and other standard encryption schemes entirely in javascript. The library seems very nifty, but I don't know of a reasonable use case for it.

As some questions have already pointed out, client side encryption is not a safe way to pass secure data to a server. HTTPS should be used instead. So, are there any projects that would benefit from or require client side encryption?

Community
  • 1
  • 1
Ben Haley
  • 2,549
  • 2
  • 18
  • 19

3 Answers3

11

Use Case 1

How about local storage? You might want to store some data, but encrypt it so that other users of the computer cannot access it?

For example:

  • User connects to server over HTTPS.
  • Server authenticates user.
  • Server serves an encryption password specific to this user.
  • User does some stuff locally.
  • Some data is stored locally (encrypted with the password).
  • User wanders off
  • User comes back to site at later stage.
  • User connects over HTTPS.
  • Server authenticates user.
  • Server serves the user's encryption password.
  • Client-side JS uses encryption password to decrypt local data.
  • User does something or other locally with their now-decrypted, in-memory local data.

This could be useful in cases where you have a fat client, with lots of (sensitive) data that needs to be used across sessions, where serving the data from the server is infeasible due to size. I can't think of that many instances where this would apply...

It could also be useful in cases where the user of the application generates sensitive data and that data does not need to (or shouldn't) ever be sent to (or stored on) the server.

For an applied example, you could store the user's credit card details locally, encrypted and use JS to auto-enter it into a form. You could have done this by instead storing the data server side, and serving a pre-populated form that way, but with this approach you don't have to store their credit card details on the server (which in some countries, there are strict laws about). Obviously, it's debatable as to whether storing credit card details encrypted on the user's machine is more or less of a security risk than storing it server side.

There's quite probably a better applied example...

I don't know of any existing project which use this technique.

Use Case 2

How about for performance improvements over HTTPS, facilitated via password sharing?

For example:

  • User connects to server over HTTPS.
  • Server authenticates user.
  • Server serves an encryption password specific to this user.
  • Server then redirects to HTTP (which has much less of an overhead than HTTPS, and so will be much better in terms of performance).
  • Because both the server and the client have the encryption password (and that password was shared over a secure connection), they can now both send and receive securely encrypted sensitive data, without the overhead of encrypting / decrypting entire requests with HTTPS. This means that the server could serve a web page where only the sensitive parts of it are encrypted. The client could then decrypt the encrypted parts.

This use case is probably not all that worthwhile, because HTTPS generally has acceptable performance levels, but would help if you need to squeeze out a bit more speed.

Use Case 3

Host proof storage. You can encrypt data client side and then send it to the server. The server can store the data and share it, but without knowing the client's private key, it cannot decrypt it. This is thought to be the basis for services such as lastpass.

Spycho
  • 7,698
  • 3
  • 34
  • 55
  • Yeah that seems reasonable. I wonder if there are any projects currently using this technique? – Ben Haley Aug 19 '11 at 15:20
  • You left out the steps where after user connects to server over HTTPS, user authenticates to the server, thus assuring it's an appropriate user - otherwise anyone could connect and get the encryption key. – jfriend00 Aug 19 '11 at 15:21
  • Ben / @jfriend00: I thought of a second use case, which I have added to the question. What do you think? – Spycho Aug 19 '11 at 15:59
  • 3
    The big overhead with HTTPS is in establishing the connection because it requires extra round-trips to do the public key stuff and exchange keys securely. Once the connection is established, HTTPS symmetric key encryption of the payload is probably faster than any JS encryption just because it's native code vs. JS code. Plus, one should also remember that HTTPS provides more than just payload encryption. It also provides a level of verification that the endpoint you're talking to is who you want it to be. I don't personally think Use Case 2 is very useful. – jfriend00 Aug 19 '11 at 16:29
  • Yeah, I would agree. It's a _possible_ use though. I think it could speed up a page load where the vast majority of the page does not need to be encrypted. Using HTTPS, you would have to encrypt the whole lot. – Spycho Aug 22 '11 at 08:12
3

Like anything on the client, you can use obfuscation to make things more difficult for casual users to peek inside, but since the client would also need to have a copy of the decryptor there's nothing to stop the user from using the decryptor themselves either.

JavaScript is an insecure environment, period.

Diodeus - James MacFarlane
  • 112,730
  • 33
  • 157
  • 176
  • 3
    Insecure against the user, yes. But, as other answers have pointed out, it is sometimes useful to be secure relative to the server or other local users. – Ben Haley Aug 22 '11 at 15:45
3

One use that comes to mind is host-proofing. That is where you want to store the data on the server or store and forward through the server but not give the server access to the data.

The client can encrypt the data prior to transmission to the server and keep the private key or at least the password for the private key locally.

I believe that this is the basis for services such as lastpass.

Ritchie
  • 1,486
  • 1
  • 15
  • 19
  • I added this to the list of use cases in my answer. Feel free to edit the answer to elaborate. – Spycho Aug 22 '11 at 09:02