Skip to main content

Hard-Coded Secrets

About Hard-Coded Secrets

What are Hard-coded Secrets?​

Hard-coded secrets refer to the practice of embedding sensitive information, such as passwords, encryption keys, or API keys, directly in the source code of an application.

This practice can make it easy for attackers to identify and exploit these secrets, leading to security vulnerabilities and other types of security threats.

Hard-coded secrets are a security risk because they are often stored in plain text, making it easy for attackers to extract them from the source code. They can also be inadvertently disclosed or exposed through other security vulnerabilities, such as code injection or data leaks.

Hard-coded secrets can affect various types of applications, such as web applications, mobile applications, and desktop applications. They can also be found in infrastructure components, such as scripts, configuration files, and server software.

At GuardRails, we differentiate between different kinds of secrets and cover the below CWEs.

What is the impact of Hard-Coded Secrets?​

Hard-coded secrets can lead to various security threats and risks, such as:

  • Information disclosure: Hard-coded secrets can expose sensitive information, such as passwords, keys, or other types of confidential information, to unauthorized parties.
  • Unauthorized access: Hard-coded secrets can allow attackers to gain unauthorized access to applications, systems, or networks, perform unauthorized actions, or modify data.
  • Data modification: Hard-coded secrets can allow attackers to modify data or system configurations, leading to data loss or corruption, or other types of system instability.

This has led to many high-profile breaches.

How to prevent Hard-Coded Secrets?​

To prevent hard-coded secrets, implement appropriate security measures, such as:

  • Use environment variables: Use environment variables or configuration files to store sensitive information, such as passwords or keys, instead of hard-coding them in the source code.
  • Use secure storage: Store sensitive information in secure storage, such as a secure key vault, that provides additional security features, such as access controls and encryption.
  • Use encryption: Use encryption to protect sensitive information in transit and at rest, such as using TLS for network traffic and encrypting storage media.
  • Apply access controls: Apply access controls to limit the privileges and actions that users or applications can perform on sensitive information, such as using role-based access controls or fine-grained access controls.
  • Use secure coding practices: Follow secure coding practices, such as code reviews, vulnerability scanning and testing, and threat modeling, to ensure that the source code is free of vulnerabilities and that sensitive information is properly protected.

A list of popular secure key vault software can be found below:

  1. HashiCorp Vault
  2. AWS Secrets Manager
  3. GCP Cloud KMS
  4. Microsoft Azure Key Vault
  5. Confidant
  6. Keywhiz
  7. Knox

References​

Taxonomies​

Explanation & Prevention​

Training​

Configuring Elixir Applications​

Elixir applications use several configuration files for different environments and stages of the application life cycle:

  1. config.exs: Contains configuration that is used across all environments and is loaded at compile time.
  2. {env}.exs: Contains environment-specific configuration (e.g., dev.exs, test.exs, prod.exs). This is also loaded at compile time.
  3. runtime.exs: Introduced in Elixir 1.11, this file contains configuration that should be loaded and evaluated at runtime.

Secrets Management​

Hardcoding secrets in the configuration files (config.exs, {env}.exs, or runtime.exs) can lead to security vulnerabilities, as these secrets might end up in version control systems and could be exposed. It's recommended to use environment variables or a secrets management tool to handle your application secrets.

For instance, instead of hardcoding a secret_key_base in config.exs, you could fetch it from an environment variable:

config :my_app, MyApp.Endpoint,
  secret_key_base: System.get_env("SECRET_KEY_BASE")

In runtime.exs, it would look like:

config :my_app, MyApp.Endpoint,
  secret_key_base: System.fetch_env!("SECRET_KEY_BASE")

Note the difference: System.get_env/1 used in config.exs and {env}.exs files will return nil if the environment variable isn't set, while System.fetch_env!/1 used in runtime.exs will raise an error if the environment variable isn't set.

In a production environment, the prod.exs and runtime.exs configuration files should not contain hardcoded secrets. Secrets should be read from the environment or a secrets manager.

If a secret_key_base is hardcoded in config.exs, it's available in all environments unless explicitly overridden in the environment-specific configuration file ({env}.exs).

By following these practices, you can ensure a secure and maintainable configuration setup for your Elixir applications.

Rotating Secrets​

If hard-coded secrets are detected for a production environment in your Elixir or Phoenix application, these secrets must be rotated. Rotation of secrets refers to the process of invalidating the current secret and replacing it with a new one.

To rotate secrets in Elixir or Phoenix applications:

  1. Generate a new secret. This can usually be done by running a mix task. For example, in Phoenix you would generate a new secret key base by running mix phx.gen.secret.
  2. Replace the old secret in your environment variables or secrets manager with the new secret.
  3. Update your application configuration to reference the new secret. If you're using environment variables, this might just involve deploying your application with the new environment variables.
  4. Verify that the application functions correctly with the new secret. Be aware that this could potentially invalidate sessions or tokens that were encrypted or signed with the old secret.
  5. After confirming the application is functioning correctly for the new secret you don't have to remove the old one from version control as it's no longer valid.

Remember, the critical aspect of secret rotation is that it must happen with minimal disruption to the application services and users. Also, in certain cases, both old and new secrets might need to coexist for a certain period (also called secret rotation window) to avoid service disruption. The length of this period will depend on your application and how it uses these secrets.

Last updated on by Stefan Streichsbier