It is a common practice to save the database connection string in the Config file in a .NET program. However, this method of saving the database connection string in app.config as plain text is less secure and not suitable for commercial use.

Although .net is open source and supports cross-platform, the best operating environment is still Windows 10. To use the Windows operating system with confidence, it is recommended that you purchase a genuine activation key.

Windows 10 Professional License 32/64-bit – OEM Key

Connection String Plain Text

In .NET programs, web applications usually store database connection strings in the Web.Config file, desktop applications are stored in the App.Config file, and they are usually recorded in clear text. However, using plaintext for recording, once the information is leaked, it is equivalent to directly exposing the database, and the security is very low.

The .NET web application only saves the configuration file on the server side, while the desktop application published by ClickOnce saves the App.Config file locally on the client, and its security issues are more prominent.

To this end, I specifically tested the deployment of an ERP helper released by ClickOnce within my company. After the Internet query, in the installation directory of the program, anyone can directly view the database configuration information through the App.Config file. As long as you have a little knowledge of program development and database knowledge, you can directly obtain the address and account password of the database in this way, which is very dangerous.

Encrypted Connection Strings .NET

After discovering this problem, I mentioned the work of encrypting the connection string to the most urgent list. Through Google search, I probably learned that common string encryption has two kinds of symmetric encryption and asymmetric encryption. The DES method is representative of symmetric encryption, and DES is relatively simple, while the RSA method is representative of asymmetric encryption.

The threshold for RSA encryption programming is high and will not be discussed here. I searched the DES encryption sample program for research. The basic idea of DES is:

  1. Encrypt the original connection string through the program
  2. Replace the original plaintext connection string in the App.Config file
  3. Decrypt it when the program is running.

Basic DES encryption and decryption operations are relatively simple. Beginners can download the sample program online and read the steps carefully. The only caveat is that the key used for DES encryption must be 8-bit.

Encrypted code

public static string DESEncrypt(string encryptingData,string key)
{
    DESCryptoServiceProvider des = new DESCryptoServiceProvider();
    des.Key = ASCIIEncoding.ASCII.GetBytes(key);
    des.IV = ASCIIEncoding.ASCII.GetBytes(key);
    byte[] encryptingBytes = Encoding.Default.GetBytes(encryptingData);    MemoryStream ms = new MemoryStream();
    CryptoStream cs = new CryptoStream(ms, des.CreateEncryptor(), CryptoStreamMode.Write);
    cs.Write(encryptingBytes, 0, encryptingBytes.Length);
    cs.FlushFinalBlock();
    StringBuilder sb = new StringBuilder();
    foreach (byte b in ms.ToArray())
    {
        sb.AppendFormat("{0:X2}", b);
    }    return sb.ToString();
}

Decryption code

public static string DESDecrypt(string decryptingData,string key)
{
    byte[] decryptingBytes = new byte[decryptingData.Length / 2];    for (int i = 0; i < decryptingBytes.Length; i++)
    {
        int data = (Convert.ToInt32(decryptingData.Substring(i * 2, 2), 16));
        decryptingBytes[i] = (byte)data;    }    DESCryptoServiceProvider des = new DESCryptoServiceProvider();
    des.Key = ASCIIEncoding.ASCII.GetBytes(key);
    des.IV = ASCIIEncoding.ASCII.GetBytes(key);    MemoryStream ms = new MemoryStream();
    CryptoStream cs = new CryptoStream(ms, des.CreateDecryptor(), CryptoStreamMode.Write);
    cs.Write(decryptingBytes, 0, decryptingBytes.Length);
    cs.FlushFinalBlock();
    StringBuilder sb = new StringBuilder();    return Encoding.Default.GetString(ms.ToArray());            
}

Handling ClickOnce Cache

A small problem that doesn’t look high but requires attention: The published program is encrypted using the connection string, and the old version of the configuration file is still saved in the local folder after the client is updated. So I re-released it again, and the local remaining plaintext configuration file disappeared completely.

My guess is that it’s possible that ClickOnce will automatically save the current and previous versions of configuration file for program rollback, so that after the update, the previous historical version will still be saved on client.