How to hide my server IP variable in a winforms application_问答_开发者

what's the best way to hide/protect a string that contains my server IP address in C# w开发者_高级运维informs application?

here is the thing, in order to activate the application I created, the user should fill up some form that contains username and password textboxes and then connect to my server in order to verify his entered details.

now what I want is to hide/protect or maybe somehow encrypt the string that contains the server address so no one can actually change/access it or at least make it very hard to be reversed.. is that possible?

I'm not sure if I'm clear with the question but I hope you guys got the idea..

This is a ludicrous approach. Security through obscurity is very weak to begin with, and the IP address you're connecting to doesn't just show up in your source code, but in outgoing packets, firewall logs, connection tables, packet captures, etc.

Hiding the peer IP address of a connection is a big area of interest and leads to techniques such as onion routing. Hiding the address in your source code is the least of your worries. And when you do use onion routing, the destination IP address won't even appear in your source code, only some cookie that is meaningful only to the next-hop onion router, so obfuscating source code becomes a non-issue.

EDIT: Based on comments, it's now clear that what's wanted is verification of the identity of the remote computer sending a response. There are ways to accomplish that, but protecting source code is not one of them. IP addresses can be spoofed, and easily. A public key stored in your application binary can be overwritten, or the authentication code can be bypassed completely.

Really, you'd need some vital function in your program to not be included in the installer, but downloaded as part of the authentication process (then the server can choose not to send it if authentication fails). There's still a possibility that the response can be stolen and used to activate additional installs without authentication, but this can only be done by someone who could validly authenticate at least once.

If you're worried about that, then you'd need to use steganography to encode the client's identity in the response. Then when illicit copies start appearing, you know which valid user made the first copy.

Or keep the proprietary parts of your software on your server, and don't ever download them to the client. This is the safest method.

Why do you need to obscure the IP address of your server?

Presumably, your application is going to contact your server and await some response before activating. In which case, I don't think that hiding an IP address is the way to do it. Not least because IP addresses are potentially volatile. Instead, you should simply use mutual authentication between the client and server. I'd suggest:

Use DNS to resolve your server's IP address. Don't worry about the fact that this can be sniffed and even spoofed.
Use standard public/private key cryptography.

The application encrypts the data to the server using the public key. The server then decrypts that with the private key. A fake server wouldn't be able to decrypt the data and a fake application wouldn't be able to encrypt the data.

The server then encrypts the response using the private key and the application decrypts it using the public key.

The best way to implement public/private keys is to use certificates. Install the private certificate on the server. Have the application installer install the public certificate (usually a .cer file, generated from the private certificate) and mark it as non-exportable (to prevent someone copying it to another machine).

EDIT: Ben made a valid point that I was just in the process of investigating. Better than installing the certificate may be to embed it in an assembly that you ship with your application and sign that assembly with a strong name (.snk file). This will ensure that the certificate can be used to encrypt/decrypt the traffic but cannot be modified (because the assembly won't load if it's tampered with).

Then use the CryptoAPI to encrypt/decrypt your data.

Oh, and you might choose to use HTTPS to communicate with your server, too.

Don't try to roll your own encryption/decryption. You won't be as good as the people that have already done it, or the people that try to crack it.