1

I have built a python script that uses python socket to build a connection between my python application and my python server. I have encrypted the data sent between the two systems. I was wondering if I should think of any other things related to security against hackers. Can they do something that could possibly steal data from my computer.

thanks in advance for the effort.

I have encrypted the data sent between the two systems.

  • The title asks about the security of the connection - i.e. it is about securing the communication. The body asks about stealing data from the system - i.e. it is asking about securing the communication endpoints. These are different things. Also, "encryption" can be done poorly and can be done will, it is unknown what you are doing. – Steffen Ullrich Nov 15 '22 at 20:30

2 Answers2

1

If the data is encrypted using a good decryption (AES for example) and the decryption is key is send safely your data is safe. The only other thing I can think about is adding a password or another authentication before accepting data sent to you via socket.

Edit: If you keep the connection open, it's always a good sign to create authentication method so random people won't be able to send you random data.

Guy Markman
  • 426
  • 1
  • 4
  • 14
  • If you want me to create an example authentication method, just write and I'll come up with something. – Guy Markman Nov 15 '22 at 20:08
  • 1
    I now encrypt my data through python fernet. And I already have a certain hanshake that must happen before the data is sent so that password will probably not be necessary then I guess. –  Nov 15 '22 at 20:10
  • It sounds good enough for me. – Guy Markman Nov 15 '22 at 20:10
  • if you want you can always make an example, I can always learn something from that. i am quite new –  Nov 15 '22 at 20:11
1

Encryption is generally a good step, but there are still some subtle concerns, e.g.:

  • An attacker can capture an encrypted message and replay it by resending the ciphertext without knowing the encryption key. If it causes a command (such as turning on a lamp or coffee machine, rebooting, etc) the attacker can rerun the command.
  • Similarly, certain types of encryption are vulnerable to an attacker piecing together pieces of ciphertexts to create a frankenmessage that will decrypt properly (e.g. with AES-ECB).
  • Your handshake (per your comment) seems to be more security-by-obscurity than a reviewed means of security.

There are off-the-shelf protocols, like the well-known TLS, that provide fairly comprehensive protection. If you can easily add this layer to your sockets (even with hardcoded, self-signed certificates that you distribute to both machines and verify) you already gain significant security over DIY encryption. As you adopt more of the TLS ecosystem, such as a certificate authority and PKI, you may be able to gain further security benefits for some threat models.

There are other theoretical risks, such as an attacker taking advantage of buffer overflow issues to try to gain remote control of the server. Python 3 is generally a good language as far as memory safety, but it's a good idea to make sure that your libraries and machine stay up to date.

If your threat model isn't concerned about this, then you're likely fine. Further, if this is a personal project, you may even want to try to deploy it, and then break into it yourself (knowing everything other than the encryption key) as a further learning exercise.

nanofarad
  • 40,330
  • 4
  • 86
  • 117
  • The data actually sent between the server and the client is an encrypted license key. this license key has an expiration date and until it is not reached the client will continue to work. So the security lies with the clients rather than the server to me. The server itself is also at google and this itself would apparently have the best security available. –  Nov 15 '22 at 20:18
  • In that case - a few questions to think about: what if a user of the client captures the conversation with the server and replays its ciphertext (from a fake server) after the license expires? Or they reverse engineer the client and remove the license check? You should also note that while Google Cloud *is* secure as far as Google's side of keeping your applications secure, it doesn't magically mitigate vulnerabilities in the actual code you write and deploy there (but the second-to-last paragraph of my answer already addresses this) – nanofarad Nov 15 '22 at 20:20
  • And how could I counteract this? 'what if a user of the client captures the conversation with the server and replays its ciphertext (from a fake server) after the license expires?' –  Nov 15 '22 at 20:24
  • TLS is an example of a mitigation - it includes active negotiation in both directions, so the client will immediately know if the server is an impostor that just replays prerecorded responses, because it won't be able to negotiate the connection successfully. But in the end, you rely on the client remaining unmodified if the license check is used to control whether the client can run (unless the server is also doing the useful work for the client and user) – nanofarad Nov 15 '22 at 20:25
  • okay thank you for the information, I will work on this normally this should work. –  Nov 15 '22 at 20:27