0

I'm not really experienced in website and specially website security.

Before the problem, let's explain the context :

I have created a web page that is meant to be a platform with an order form X to be filled by some client A with some critical fields Y to be encrypted. Then, the web server would send a mail with X+Y to the seller B, so he can process the order.

What I did :

I created a form with Spring MVC with a controller (in Java) and an HTML view template. This tutorial helped me a bit : https://spring.io/guides/gs/handling-form-submission/. When A submits X+Y, I encrypt Y (with a symmetric TEA Encryption) in the Controller (So I guess that is obviously server-side) and then send it to the retailer by mail. Then the retailer decrypts it with the same key used for decryption.

The problem :

I would like it to be really secure so I don't want to send Y to the server and then encrypt it, I want to encrypt it on the client side and then send it to the controller.

Is Javascript client-side the only solution to do this ? I would prefer to do it in Java on the client side because what I want is that the encryption is client-side and also the source code containing the encryption algorithm hidden to anyone (which is not the case I guess in HTML and Javascript).

So, for client-side and hidden source code encryption, is it possible to do it with Spring MVC and Java, or with Javascript, or do you have any other suggestion ?

red.and.black
  • 33
  • 1
  • 5
  • 1. Yes it pretty much has to be JS to run on the client side. 2. It's not the encryption algorithm you worry about leaking (if it's a good one it doesn't matter) it's the keys. 3. If you're worried about in-transit security, *use HTTPS*. – jonrsharpe May 21 '16 at 08:11
  • Thank you for your fast answer @jonrsharpe. Then why I would encrypt with TEA if I use HTTPS with fields not encrypted for the first transit to the web server ? I'm not an expert of HTTPS protocol so I would be happy if someone explains me better. – red.and.black May 21 '16 at 08:15
  • Because apparently you want to send it encrypted in an email; I don't know why, *that's the requirement you came with*. HTTPS would protect the hop from client to your server, then TEA protects the email from server to retailer. – jonrsharpe May 21 '16 at 08:16
  • Using symmetric encryption over HTTP or TCP does not any real security, because the key must be sent along with the ciphertext. It's nothing more than obfuscation. An attacker who observes the traffic can directly decrypt the ciphertext you're trying to protect. You need to create a secure channel between the browser and the server. A common way to do that is using HTTPS with a properly signed public key (certificate). – Artjom B. May 21 '16 at 10:32
  • Hey @Artjob B., Actually I don't send the key itself but a hint to find the key in a shared library that was shared over another media. But the problem is that I want the encryption to be done on the client side rather than on the server side (With only binary code access but no access to source code) – red.and.black May 21 '16 at 13:56
  • Any other suggestion ? – red.and.black May 22 '16 at 05:51

1 Answers1

0

As indicated, I wouldn't worry about people having access to the encryption code itself, this is the least of your concerns security-wise. There are publicly-available reference implementations and specifications for all common encryption algorithms anyway. A major requirement of modern cryptographic algorithms is that the security lies in the secrecy of the key, not in the secrecy of the algorithm itself. (This was actually an explicit requirement for the Data Encryption Standard and has held for all subsequently-designed algorithms). Relying on the secrecy of the encryption algorithm you're using is a form of security by obscurity, which is a bad practice.

There's a decent discussion of public-key cryptography in JavaScript here: Are there any asymmetric encryption options for JavaScript?

Community
  • 1
  • 1
EJoshuaS - Stand with Ukraine
  • 11,977
  • 56
  • 49
  • 78