0

So I have ran into huge problem. So the problem is following, when I compile my C# project, that contains a function to connect to a MySQL server, my string for connection is visible when decompiling my project with ILSpy.

My function goes like this

void ConnectToDatabase()
{
    string myConnectionString;
    myConnectionString = "Server=sql7.freemysqlhosting.net;UID==**********;Pwd==**********;Database=**********;";

    try
    {
        conn = new MySql.Data.MySqlClient.MySqlConnection(myConnectionString);
        secondconn = new MySql.Data.MySqlClient.MySqlConnection(myConnectionString);
        secondconn.Open();
        secondconn.ChangeDatabase("information_schema");

        conn.Open();
        ConnectionEstablished(true);
    }

But this is the problem enter image description here

Is there any work around for this? Even if I went trough server side connection to check things for MySQL, how could I connect without spitting out my info.

Thanks.

Shame123
  • 103
  • 13
  • 3
    Put it in the `config` file and then encrypt it – Izzy Jun 23 '16 at 06:59
  • 1
    Wouldn't it cause the same problem since you could just decompile it and see the encryption key yourself, thus making you able do de-crypt yourself. – Shame123 Jun 23 '16 at 07:00
  • 1
    Regardless of wherever you put the credentials info, it will be extractable using decompilers so, better to use some obfuscation to protect it from decompiling. Use free or paid tools to do obfuscation. example Eazfuscator.Net. Search more tools as per your requirements. – Munawar Jun 23 '16 at 07:03
  • So there is no any other way? Since there are a lot of deobfuscators and if someone wants to view the source so badly he will eventually get it. Wow this is a shame with C# and other so easily decompilable languages. – Shame123 Jun 23 '16 at 07:05
  • 1
    If the code is running on someone else's machine, you should assume they can always discover any "secrets". The only solution is to keep your secrets on machines that *you* control. I.e. introduce a *server*, have the clients connect to your server, and have your server talk to MySQL. – Damien_The_Unbeliever Jun 23 '16 at 07:07
  • 1
    That's a problem common to every kind of application that connects freely on the net to a remote database. Sooner or later you should send your password to the remote server and whatever goes along the wire could be read. The best choice is to not do so and have a remote service (a WCF for example) that is able to authenticate your user through different methods (a certificate) and all traffic going through HTTPS. Still not fool proof though. – Steve Jun 23 '16 at 07:07

2 Answers2

2

You could use a webservice to provide a config file or a connection string to a trusted machine on rogram startup. You could then either prompt the User for user credentials to the Webservice or use a certificate. This way the actual Database Password is not "stored" on the User Machine and you could ban Machines/Users/Certificates centrally. Please beware the usual webservice security measures apply (Use HTTPs, Use Strong Crypto, Do not self rolled crypto, Use Session etc)

knechtrootrecht
  • 383
  • 2
  • 11
  • So basically I should establish http connection for lets say "php" server, sent get method or post and see if user exsists, and if it does, sent database info back? – Shame123 Jun 23 '16 at 07:09
  • 1
    If you are already using C# I would reccomend WCF, it is very easy to do a basic webservice in it and if you only have a Linux/Unix Server it should also work with [mono](http://www.mono-project.com/docs/web/wcf/). A basic http client would also work. But i dont know if the it has buildin certificate support (I mean somthing like certificate revocation). it is basic http i would suggest upon startup you promt for user credentials send them to your Backend, validate there, and if it passes then send back a connection string. Ideally a temporary one which is valid only a limited time – knechtrootrecht Jun 23 '16 at 07:13
  • 1
    Also be aware that it could still be read form memory maybe [SecureString](https://msdn.microsoft.com/en-us/library/system.security.securestring.aspx#HowSecure) helps to mitigate at least some of this problem – knechtrootrecht Jun 23 '16 at 07:20
  • Ill check WCF thing out, I've got 0 experience in it though. Thanks for answer! – Shame123 Jun 23 '16 at 07:21
  • 1
    This [Tutorial(https://msdn.microsoft.com/en-Us/library/bb386386.aspx) taught me everything I needed to get started. WCF in general is quite a usefull technology if you just want to get data from A to B – knechtrootrecht Jun 23 '16 at 07:31
  • "beware the usual webservice security measures apply" - but the "attacker" in this case is the owner of the machine on which this code is running. They can defeat most of these measures by using an intercepting proxy (e.g. fiddler), installing new root certs, etc. They can also debug the application. There really is no safe way to be able to hand the connection information down to the client and for it not to be discoverable. – Damien_The_Unbeliever Jun 23 '16 at 07:32
  • There is no safe way, this is correct. But in by providing user Authentication via a Webservice you can at least shut out malicious users, which is as good as it will get. There is of course no such thing as an unbreakable system. – knechtrootrecht Jun 27 '16 at 07:04
0

There is no way to make it foolproof 100% but to protect it from ordinary/regular users encryption, obfuscation should be enough.

The applications that need to be deployed on customers local system must be obfuscated to protect anything that is not supposed to be visible to end users.

Encryption is can be used to store the info on local system but the code performing encryption/decryption must be protected form decompilation by using code obfuscation.

Since its a client application(winform) so, you need connection info on the client computer. I would recommend to use obfuscation, its fairly easy by using tools.

Its common issues and there is lots of help available: List of obfuscation tools for .Net

Many similar questions are already answered:

How can I protect my .NET assemblies from decompilation?

Protect .NET code from reverse engineering?

Community
  • 1
  • 1
Munawar
  • 2,588
  • 2
  • 26
  • 29