smartnode
smartnode copied to clipboard
rocket-pool
[FIX] Allow mnemonic recovery via file
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:
api wallet recover --mnemonic-file <(gpg --decrypt /path/to/encrypted-backup)
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.
@jshufro this is going to obviate your one-word-at-a-time verifier, want to give it a look?
This changes the api container, which is downstream. The word-at-a-time flow passes the full mnemonic to the mnemonic flag, so it isn't obviated.
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 docker run semantics?
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.
I've updated the MR to make this backwards compatible, given the interaction between the node and api containers.