Enhance Configuration Variables with Secure Encryption and Session Management

[mshakeg]

Background

Hardhat introduced configuration variables as a way to manage user-specific values and sensitive data separately from the code repository (as per issue #2265). While this was a step in the right direction, the current implementation stores these variables in plain text, which is not ideal for highly sensitive information like private keys.

Feature Request

We propose enhancing the existing configuration variables feature with built-in encryption support and secure session management to provide a more robust solution for managing sensitive data.

Proposed Functionality

1. Encryption at Rest:

   • Implement strong encryption (e.g., AES-256) for storing configuration variables on disk.
   • Use a master password or key to encrypt/decrypt the variables.

2. Secure Session Management:

   • Implement a secure session system where users only need to enter the master password once per Hardhat session.
   • The session could be initiated when Hardhat first attempts to access a sensitive variable.
   • Securely store the derived encryption key in protected memory during the active session, implementing safeguards against memory dumps and ensuring the key is securely erased when the session ends.
   • Provide explicit commands for starting, checking, and terminating sessions.
   • Automatically terminate sessions when the terminal is closed or after a configurable idle timeout.

3. Classified Variables:

   • Allow users to mark certain variables as "sensitive" to enforce stricter security measures.
   • Sensitive variables are encrypted on disk but can be accessed freely during an authenticated session.

4. Secure Input:

   • When setting sensitive variables, provide an option to input values securely (without echoing to the terminal).

Benefits

• Significantly enhanced security for sensitive data like private keys and API tokens.
• Maintains the ease of use of the current configuration variables system.
• Improves developer experience with session-based authentication.

Potential Implementation

// Setting a sensitive variable
$ npx hardhat vars set --sensitive PRIVATE_KEY
✔ Enter value: ********************************

// Manually start a session (optional, as it will auto-start when needed)
$ npx hardhat vars session start
Enter master password to start secure session: ****
Secure session started.

// Check current session status
$ npx hardhat vars session status
Secure session is active.

// Manually terminate a session
$ npx hardhat vars session end
Secure session terminated.

// Session auto-starts when accessing sensitive variables
$ npx hardhat deploy
No active session detected. Enter master password to unlock sensitive variables: ****
Deploying contracts...

// Using in configuration
const { vars } = require("hardhat/config");

module.exports = {
  networks: {
    mainnet: {
      url: `https://mainnet.infura.io/v3/${vars.get("INFURA_API_KEY")}`,
      accounts: [vars.get("PRIVATE_KEY")], // Will be automatically decrypted if in an authenticated session
    },
  },
};

Questions for Discussion

1. What encryption standards should we use?
2. How long should a secure session last by default? Should we provide options for configurable session timeout?
3. Should sessions be tied to specific terminal instances or be system-wide?

We believe this enhancement would significantly improve the security posture of Hardhat projects, especially for teams working with valuable assets on public blockchains, while maintaining a smooth developer experience.

Search terms

secrets encryption configuration variables

[kanej]

We are currently working on the next major version for Hardhat, and this a key requirement of our next version of configuration variables.

[ChristopherDedominici]

Closing this issue as it is being addressed here