decred
Staking: Purchaseonly ticket buyer wallet option
Problem:
When doing solo staking, even when using a dual wallet with a voting-only wallet, the hot wallet which does the automated ticket purchase has to remained unlocked and is at risk of moving funds if someone is able to access the system with login privileges.
The same problem would apply for someone doing staking with a pool and wants to use the automated ticket buyer. The remaining balance in the wallet remains at risk even if the majority of the funds are held in tickets, or when proceeds for voting are returned to the wallet and the ticket price is too high, the funds would sit in the wallet for a period of time being at risk of being transferred out.
Solution:
dcrwallet should have an option to start the process in "ticket-purchase-only" mode where even if the wallet is unlocked it can only be used to buy tickets or receive funds but funds cannot be transferred out without unlocking again in "full" mode or restarting the process.
Workaround:
The only current safe option is to have the ticket buying wallet be cold wallet but it cannot automatically purchase tickets in this case and requires a manual process every few days to unlock the wallet for purchasing tickets.
What is the wallet protected by in such a mode?
From my perspective:
-
Physical access and memory dump attacks are still possible (and there's nothing we can do about it at the application level)
-
All RPCs are permissioned, so there's no way to perform such an attack over RPC without also having the authentication details (user/pass for JSON-RPC) or the passphrase itself (gRPC API).
If someone is able to get root access on the system where the wallet is running and unlocked, a user simply has to use dcrctl and issue a sendtoaddress to move the funds in the existing wallet. When you have root access or get that user account compromised, this is easily done. Other possible attack vectors include a maliciously script that would run the dcrctl command for example, this could be bundled as part of a malware or malicious software installer. That's much easier than looking at attack vectors with a memory dump.
If the dangerous RPCs would be blocked at the daemon level and only allow ticket purchase, then even if an attackers gets the user credentials or root access (or run commands on behalf of the user via a malicious script or software), then the funds are not able to be moved at least.
The RPC authentication details are just in plain text in a file which is readable by the user or root. Even if you pass them on the command line, you can see them by looking at the ps output or shell history file. They would have to be interactively prompted similar to the passphrase interactive mode. But I think a restricted mode to open the wallet with limited RPC available would avoid easy attack vectors.
If someone has root access to your wallet host, they can dump the process memory, and it's game over. If you are running a wallet on a multiuser machine (which is not recommended), set your wallet config to 0600 to prevent other users from reading it. Both of these are opsec concerns which dcrwallet cannot fix or prevent.
Run your wallet as a dedicated user, using a dedicated machine, and restrict physical access to the machine. Software can only do so much, you must also have smart opsec.
This is currently what I'm doing as best practices, however there are sometime remote access vulnerabilities which are found and even if the system is well protected, the chances are still there, or someone can package up a malicious script as part of a software update (which you have to run as root to install system packages). I think most people that are staking are using the automated ticket buyer and there should be better best practices established to protect the user funds if no software change is possible to add additional protection.