Reputation: 13964
I'm building a desktop application that connects to a web server and communicates through a socket-based API. I want to ensure I only talk to my application, and not any third party hacker. Communication is encrypted over https. In addition, a private/public key pair are used for authentication. Basically the time, private, and public key are hashed together and sent to the server with the current time and public key to the server.
I'm concerned that if others reverse engineer the application, they will discover the hashing function, connecting url, and private key, as normally strings are stored in clear text in compiled applications.
I have two thoughts to mitigate this:
Am I on the right track? How do I keep the secret key secret?
Upvotes: 0
Views: 44
Reputation: 322
Encryption is not the correct solution. No matter how well you hide the implementation, a determined attacker with a sufficient amount of time can reverse-engineer it.
At the very least, an attacker can determine where the encryption/hashing is done and dump the memory of the process right before that to examine the secrets in plaintext.
Your best bet would be to a) obfuscate the code and add anti-debugging defenses (not perfect, but it will discourage script kiddies and slow down determined attackers) and b) hardening as much as you can server-side
Basically, you can never rely on the client because you don't control it. Your best bet is to make sure any critical processing is done server-side so a custom client can't do anything malicious.
For example, if you were making a multiplayer chess game, you'd want the client to just submit basic actions (a move) and you'd track board state on the server. It doesn't matter if the client is hacked because if an illegal action is submitted, you just return an error.
Upvotes: 1