I wanted to post this here hoping we could get some constructive discourse surrounding potential solutions and caveats. It also serves to mark the record that this was brought up, in the event that these security weaknesses inevitably result in people losing a lot of money. Hopefully solutions can be implemented before that ever happens. So, to cut to the chase, at the moment there are big issues with the way passphrases are handled with dcrwallet and dcrctl. Firstly there's the option to pass through a passphrase on the command line using `walletpassphrase`. This is fairly insecure to begin with due to the fact that your password will be logged to history. A lot of applications choose to remove this option all together and replace it for an alternative (like an environment variable that points to a password file in the case of psql for Postgres, for example) because having passwords in history is obviously very undesirable. For the applications that do support this sort of thing (env var pointing to file), it is only mainly available as a fallback for people who require the password to be easily passable to the application in the case of third-party scripts and applications, but it is not the secure or recommended way of handling passwords and is more of a 'catering to use cases' type deal. For a relational database, maybe this is okay, but for a wallet that could be storing hundreds of thousands of dollars it is not ideal. The most secure way is obviously a password prompt by the application (like the password prompt you receive when launching `dcrwallet` with `--promptpw`). As it stands, there is no option for this in dcrctl, you either have to launch your `dcrwallet` with `--promptpw `which will PERMANENTLY unlock your wallet daemon (this is really bad), or you can pass it in through the `dcrctl walletpassphrase` command line (also bad). A one-time-use `dcrctl` password prompt feature is sorely needed. But, there's a further problem with the current way of passing it through the `dcrctl` command line. Instead of it being a single use password (in other words you pass it through along with the wallet command you're executing, for example, something like: `dcrwallet --wallet sendtoaddress x --password=abc` -- you actually have to fire two calls, one to unlock the wallet with a **timeout** using `dcrctl walletpassphrase`, and one to pass through your `dcrctl` wallet command like `sendtoaddress`. This is bad because now you have the possibility of a third party hijacking your funds during that timeout window. I can see at least one reason of why it was implemented (so that you don't need to leave your password in a file when using `dcrctl` in scripts), but I'm not entirely convinced it's worth placating to. If you really think this is a necessary feature due to the use case, no problem, but at least provide a more secure alternative like a `--password` flag along with the `--wallet` flag. Broken down into use cases, so things are a bit more clear: * Users who want to execute `dcrctl` in a script after the wallet is MANUALLY unlocked. - This requires use of something like the current `walletpassphrase` command unlock mechanism due to the events being decoupled. Probably a pretty niche use case, but it does exist. This solution is clearly the only one available due to the decoupling that has to happen, but should this be a supported use case? Maybe that's worth thinking about a bit more. * Users who want to execute `dcrctl` in a script and automatically unlock the wallet. - This requires users to pass in the password through the command line, as it stands there is no way to do this securely. `walletpassphrase` will work if you fire off two separate commands of course, but this is less secure than a `--password` flag that can be passed along with `--wallet`. This should at least be an option since it is the more secure of the two for this use case, and arguably it's the more common use case than the one above too. * Users who want to manually execute `dcrctl` commands. - This currently requires users to use `walletpassphrase`, which is not as secure as possible alternatives for the above mentioned reasons. `--wallet --password` is not a recommended solution here because of the possibility of logging to history. The ideal solution for this use case (which is the most common use case for CLI-favoring users) is a `--promptpw` option that **only** unlocks the wallet for the duration of that single command (opposed to a timeout like `walletpassphrase`). This is sorely needed. I understand that a terminal provides you with ways to get around the issue if you're being creative, but for something so security intensive it should come with the tool and be the default, not something that requires additional knowledge. Of course, in these use cases above, you can also use `dcrwallet --promptpw` to permanently unlock your wallet, but it goes without saying that this is the least secure option out of all, and it should *NEVER* be used. But this brings up another problem -- as it stands, if you want to PoS mine, you have no choice but to run the `dcrwallet` with `--promptpw`. Now anyone can walk up to or infect your system and steal all of your coins with extreme ease. For PoS mining this is such a big security weakness that I don't think people should actually be PoS mining using these tools at the moment, unless you're only playing with a small amount of funds. You can obviously mitigate the risk by using a VM or something, but even still, it's sketchy. Solutions for that would be: * Provide a way to launch `dcrwallet --promptpw` in a `mining only mode`, so that it is not able to act on RPC commands that send coins from your account (or any other potentially malicious commands). * Force a reprompt of the password for all RPC commands sent through `dcrctl` when mining is enabled and activated, aka invalidate the "permanently unlocked" mode for RPC, and only permanently unlock for the `dcrwallet` mining component. Another thing worth mentioning is the fact that `--terminal` is deprecated (in master), which would have provided some avenue to avoid the history logging issues, but it doesn't look like that supported the `walletpassphrase` command anyway. As a CLI user I really do like that mode, and I'm sad to see it go, but I understand it requires extra dev upkeep and you're transitioning to make the daemons and dcrctl more specifically tailored to GUI piping. GUI's should still however have access to the more secure modes of password interaction mentioned above. -- With all that said, thanks for your commitment to such an amazing project. I have high hopes for its future. It's a great piece of tech.