Skip to main content

Non-encrypted confidential information - Base 64

Need

Secure storage of confidential information

Context

  • Usage of C# for developing robust and efficient applications

Description

Non compliant code

public class AppSettings
{
public string SecretKey { get; set; } = "VGVzdFNlY3JldEtleQ=="; // "TestSecretKey" in Base64
}

The above code represents a common way to handle application settings in an ASP.NET Core application. In this case, a secret key is stored in the AppSettings class and is then read into the application at startup.

The vulnerability lies in the fact that the secret key is stored in Base64 encoding, which is not a secure method of storing confidential information. Base64 is a method of encoding binary data, and while it may appear unreadable at first glance, it can be easily decoded to reveal the original information. In this case, the secret key "TestSecretKey" is stored as "VGVzdFNlY3JldEtleQ==".

This means that anyone who has access to the source code or compiled application can easily decode the secret key, leading to a potential security risk. This is especially dangerous if the secret key is used for sensitive operations such as encryption, authentication, or signing of data.

To mitigate this vulnerability, sensitive information should never be stored in the source code directly. Instead, it should be stored in a secure manner, such as using the .NET Core's Secret Manager in development and Azure Key Vault in production.

Steps

  • Remove the hardcoded Base64 encoded secret key from the source code.
  • Store the secret key in a secure configuration file or environment variable.
  • Encrypt the secret key before storing it.
  • Update the code to retrieve the secret key from the secure configuration file or environment variable at runtime.

Compliant code

public class AppSettings
{
public string SecretKey { get; set; }
}

The original code had a hardcoded Base64 encoded secret key in the source code. This is a security vulnerability because anyone who has access to the source code can see the secret key.

The updated code removes the hardcoded secret key from the source code. Instead, the secret key is stored in the appsettings.json configuration file. This is a more secure way to store sensitive information because the configuration file can be encrypted and is not typically included in the source code repository.

In the Startup.cs file, the ConfigureServices method is updated to retrieve the secret key from the AppSettings section of the configuration file at runtime. This means that the secret key is not loaded into memory until it is needed, which reduces the risk of it being exposed.

Please note that storing secrets in the appsettings.json file is okay for development, but not suitable for production. In a production environment, you should use a secure store for your secrets, such as Azure Key Vault or AWS Secrets Manager. You can also use environment variables to store secrets.

Remember to never store secrets in your source code or version control system.

References