[FIX] Allow mnemonic recovery via file #365
Conversation
The only way to `recover` was to specify the mnemonic as an input via STDIN. This carries a number of risks, as that mnemonic could be exposed via process monitoring, shell history, or over the shoulder observation. I believe allowing the user to specify a file to recover from is a generally more secure path to recovery from a mnemonic.
|
@jshufro this is going to obviate your one-word-at-a-time verifier, want to give it a look? |
|
My ideal usage is something like: Otherwise, I'll decrypt the backup, and write the mnemonic to a tmpfs file, recover, and then delete the plaintext. But ideally, I never have to actually see the full mnemonic. |
|
For example, if any sort of process monitoring is enabled (i.e. datadog, metrics agents on GCP/AWS), using the CLI to recover will expose that mnemonic in plaintext at least twice (once via the CLI call, which then makes a docker call to the API container). At the very least, I think the API commands should optionally support recovering from a file. If the change is deemed worthwhile, I can also modify the other recovery commands to support the same sort of logic. |
This changes the api container, which is downstream. The word-at-a-time flow passes the full mnemonic to the That said, I think this is just in the wrong place. Accessing the filesystem from the API is tricky, you need to mount the file you want into the container. Is there a reason why rocketpool-cli doesn't just support an additional flag, and pass the mnemonic to rocketpool_api via its normal |
|
Ah I see, you don't want the mnemonic exposed when the cli forks off the api call. Well, this seems fine, though now I wonder if it has any value given that the master node is stored on disk, as is the key, and anyone in the docker group can trivially decrypt it. |
|
yea, this was more motivated by potential exposure to monitoring agents, which could expose the mnemonic outside the instance itself. |
|
Yep LGTM |
|
I've updated the MR to make this backwards compatible, given the interaction between the node and api containers. |
The only way to
recoverwas to specify the mnemonic as an input via STDIN. This carries a number of risks, as that mnemonic could be exposed via process monitoring, shell history, or over the shoulder observation.I believe allowing the user to specify a file to recover from is a generally more secure path to recovery from a mnemonic.