4

For example, if I were to send a post request to a /login route, would that payload already be encrypted if the API URL is HTTPS? As far as I know, if it is in HTTPS, then the payload is already encrypted.

Another example is sending a post request that involves transferring money. Is SSL/TLS secure enough to not need a second layer of encryption using a crypto library?

I am working on a project with sensitive data, but I also don't want it to be needlessly complex with second layer of encryption if HTTPS/SSL/TLS is already enough to secure it.

Currently, the code base I am working on uses a list of keys (30 keys), the key to be used for encryption is picked randomly within that list.

The list of keys are stored in an .env file of both frontend and backend, which I thought was weird. Isn't that insecure since all the 30 keys are exposed on the frontend. I already asked various LLMs about this, All of them agree that this way encrypting payload is flawed and insecure, and not necessary since HTTPS already secures the payload. So, fellow humans, is there any advice you can give me to prevent MITM attacks? is the AI's advice correct?

Edit: Thank you everyone for your input. We have decided to exclude the second encryption layer from the old code base to the new one to keep it less complex and easier to maintain. That said, I'm not a security expert, so if you have any additional ideas or recommendations for improving payload security, while keeping it as simple as possible, feel free to share!

Improve this question
12
  • 1
    Can you specify what "frontend" and "backend" mean to you in this scenario? Since you mention .env files I suppose the "frontend" is not the web browser, but rather the server that the web browser is talking to, and the "backend" is either a database server or a second server, and thus using a different communications channel than the TLS-secured connection between the browser and the first server? What is that communications channel? What kind of encryption does it use? What kind of keys are they (especially symmetric pre-shared keys or private/public key pairs)? Commented Jan 14 at 9:40
  • 1
    @jcaron The frontend in this context is a Single-Page react application. As far as I know, when building the react app for production, anything that is in the .env file will be in the compiled js files. all 30 keys can easily be found completely bare if someone simply snoop around using dev console in the browser. the code also uses CryptoJS, which is depreciated, discontinued. link Commented Jan 14 at 10:05
  • 6
    Ah, clearer now. Indeed if (symmetric pre-shared, or private) keys are distributed they are completely useless. Commented Jan 14 at 10:11
  • 1
    @jcaron Yes it is a symmetric pre-shared key. same 30 keys on both the backend node js and frontend react app. Commented Jan 14 at 10:31
  • 1
    Shared with whom? If the keys are only shared with carefully selected users, this is valid (just poorly implemented). If anybody can get the keys, they're of course useless. Commented Jan 14 at 23:58

4 Answers 4

Reset to default
18

TLS encrypts the network traffic between two hosts and thereby prevents man-in-the-middle attacks – nothing more, nothing less. In the context of HTTPS, one of the hosts is going to be the client, and the other host is some kind of server, e.g., a web server, reverse proxy or TLS termination proxy.

Whether or not traffic encryption between the client and the server is sufficient depends entirely on your requirements. If you’re only worried about securely transmitting data between both hosts, then TLS is enough. If you have other requirements, then you may need other protocols instead of or in addition to TLS.

Since you're working on an existing code base, it may be a good idea to figure out why it was designed this way and what the original requirements are. It could be that the developers were just incompetent and failed to recognize that TLS already solves the problem, but it's also possible that you're missing some important aspect of the system which requires more than TLS.

Improve this answer
1
2

Yes, HTTPS encrypts the traffic between the closest endpoints - browser and server. Browser vendors and other parties have worked hard to make the protocol pretty secure.

You are best to focus your attention on securing everything else in your application such as handling of secrets on the backend, up to date software components, no SQL injection etc.

Currently, the code base I am working on uses a list of keys (30 keys), the key to be used for encryption is picked randomly within that list.

This is completely useless and you are best to entirely remove it from your app, not only because the key is also stored in the frontend but also randomly picking from 30 options is useless.

Improve this answer
8
  • 8
    I wouldn‘t remove anything without a deep understanding of why this feature exist. I agree that it sounds odd and might be completely useless, but none of us knows for sure (probably not even the OP). Commented Jan 14 at 7:56
  • 3
    Legacy codebases are weird. You need to be an archeologist besides being a programmer/developer. One of the things I learned over the decade worth of keeping old systems running is that YOU DON'T REMOVE THINGS WITHOUT PROPERLY UNDERSTANDING WHY IT'S THERE, because assumptions make an ass of you and me. Incompetence is extremely rarely a reason of why it was placed there, but you should investigate properly before deciding it's useless. Commented Jan 14 at 9:14
  • you might be right. The front end in this context is a react website accessible to anyone. the 30 keys can be found by anyone snooping around the browser dev tools. I am still taking precautions here. i will update my questions once i am done reverse engineering the encryption process. Commented Jan 14 at 10:16
  • 1
    @mishan I agree with you regarding legacy code. however this code base i am working on was made quite recently at mid 2024. Commented Jan 15 at 4:09
  • 3
    @MFSCraft Okay then :) This situation might be a case of incompetence :) Commented Jan 15 at 11:02
2

Client-Side Encryption Can Add an Extra Layer of Security

This is an absolute last line of defense kind of thing, but when working with systems that transfer money, it's generally a good idea. If all of your other security attempts fail, and your web server falls to an Advanced Persistent Threat (APT) or Intentional Insider Threat, it is possible for a hacker to read data after the server decrypts the HTTPs data, but before your server-side code executes to encrypt it for storage inside of your database. Or, it is possible for the hacker to analyze your application and reverse engineer its encryption method to decrypt the database. This is where Client-Side Encryption comes in. If you encrypt data in the browser before you send it, and then store that data in the database without ever decrypting it first, it will prevent the webserver from ever having the opportunity to see an unencrypted version of your data no matter how badly compromised the server is.

Based on your description it sounds like your senior developer was going for this, but probably did not do a good job of it.

Client-Side Encryption generally requires a second key server on a different network or persistent local storage capabilities on the client's machine. Persistent local storage is not something browsers are designed for; so, unless you are using an App, you are probably using a Key-Server.

The way it should work is that the web-server should have the key-server generate a random key for each user which the key server remembers, but the web-server does not. This way, when you go to retrieve your data, instead of relying on the web hosting server to fully decrypt your data, the key server sends the decryption key to the client without ever letting the web server know what that key looks like. This way, even if the hacker fully reverse engineers your system and tracks every byte of data coming and going from your web-server, he does not have what he needs to read your database. Inversely, if the key server ever becomes compromised, there is no web application or database on that network to decrypt with it. So unless the same hacker takes full control of both servers, your data remains secure.

That said, CSE can not take the place of HTTPs either. In order to function, your application server will need to be able to store at least some of its data in a unencrypted manner. So, things like key IDs, searchable data fields, etc. will typically need to be unencrypted on the web hosting server for the web application to be able know what data to send to the browser. So, even with certain data being client-side encrypted, you still need HTTPs to secure the stuff for transport that you for practical reasons can not client-side encrypt.

Improve this answer
1

For encryption you can use https, you can use a VPN, and you can have your app encrypt its data any way it likes. Or any combination.

HTTPS is pretty secure; it’s practically impossible to break. And it’s very very easy to implement it. VPN is a bit less secure, for example the VPN server could read what you send, but it hides well what is getting sent where, and if you use https over vpn then a rogue vpn server only can read your https which it cannot decrypt, and most people cannot even see your https traffic. And your app can use its own encryption so an attacker breaking vpn and https only sees your encrypted data and is still stuck.

Whether you need additional encryption beyond https is up to you. Is your information sensitive enough that unbreakable https is not unbreakable enough? Does the customer pay you for more security? Then send already encrypted data through https, and advise them how to use a VPN.

Improve this answer
2
  • thanks for your input. yes i agree https is already secure, and the reason why i asked this question is to confirm if a 2nd layer of encryption is needed because the previous dev made one, but upon further investigation, ultimately i was able to break the 2nd layer of encryption anyway since the keys are just there on the browser's dev tools. Commented Jan 16 at 13:23
  • I don’t see what exactly a VPN is supposed to do here, and describing VPNs as “less secure” than browser-server TLS makes little sense. It seems you’re thinking of (commercial) VPN providers which claim to “hide” your IP address, but this is just one purpose of VPNs and probably not very relevant in the given scenario. Of course you can have nested traffic encryption, but then you would set up your own VPN gateway on or near the target server. In this case, neither the “less secure” part (in the sense of: not under your control) nor the ”hiding” aspect apply. Commented Jan 16 at 17:52

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.