HAL-04 sensitive information in environment variables

[juniuszhou]

Description

When you store your secret keys in an environment variable, you are prone to accidentally exposing them. Given that the environment is implicitly available to the process, it’s hard, if not impossible, to track access and how the contents get exposed.

Environment variables can be exposed in a variety of scenarios and are therefore an inappropriate location for extremely sensitive information. For example, it’s common to have applications grab the whole environment and print it out for debugging or error reporting. Environment variables are passed down to child processes and can be leaked as a result. This breaks the principle of least privilege. Imagine that as part of your application, you call to a third-party tool to perform some action.all of a sudden that third-party tool has access to your environment. When applications crash, it’s common for them to store the environment variables in log-files for later debugging. This means plain-text secrets can be stored on disk.

code location

Listing 6: cmd/ebrelayer/txs/signature.go
21 func LoadPrivateKey() (key *ecdsa.PrivateKey, err error ) {
22 // Private key for validator 's Ethereum address must be set as an environment variable
23 rawPrivateKey := os.Getenv("ETHEREUM_PRIVATE_KEY")

Recommendation

Use an external key manager to store and transmit secrets.

[juniuszhou]

please @Brando753 assess the proposal if we need external key manager.

[Brando753]

In general, storing secrets in env variables is a bad idea, using a secret manager is a better solution. This will require cross-team work between chainops, sifnode, and peggy. I suggest we put this off until after Peggy 2.0 launches and then come back to it as its something we should improve.