Security Concerns That Need Somewhat Urgent Attention

Discussion in 'Technical Development' started by nullbio, Mar 29, 2017.

Tags:
  1. nullbio

    nullbio
    Expand Collapse
    New Member

    Joined:
    Mar 29, 2017
    Messages:
    6
    Likes Received:
    5
    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.
     
  2. David

    David
    Expand Collapse
    Full Member

    Joined:
    Jan 22, 2016
    Messages:
    313
    Likes Received:
    188
    Hey nullbio, it sounds like you are pointing out issues that deal more with physical computer security rather than Decred code security. As it stands, Proof of Stake mining requires a wallet to be online and unlocked to cast votes. To me, that means I better be sure my computer is physically secure from unauthorized access while PoS mining. For the record, it's not a good idea to run a Decred wallet on a library or university computer. There are several cloud based options for hosting VMs if you trust those more than your own PC... you can even stick one of the new Raspberry Pi's in your attic if you want.

    You have good points, but nobody is going to break into my house with the intent of stealing my Decred. I'd be more concerned with someone randomly guessing my seed words and creating my wallet file than someone who's familiar with the latest release of Decred coming into my house, bypassing my workstation's security settings, and shipping my Decred off to their own private wallet. People have been PoS mining for nearly a year now, with over 2 million Decred currently staked in an unknown number of unlocked wallets, and we have yet to hear about a breach.

    Regarding entering the password in the CLI and having it there in your CLI history - I 100% agree with you. It is for this reason that the promptpass option is available for use, not only as a flag for dcrwallet, but also as an entry in the dcrwallet config file, should you choose to make one. This option never enters the password into CLI history.
     
  3. nullbio

    nullbio
    Expand Collapse
    New Member

    Joined:
    Mar 29, 2017
    Messages:
    6
    Likes Received:
    5
    I understand what you're saying, but you also need to consider that it would be trivial to write a virus that retrieves your rpcuser and rpcpass from your dcrctl.conf and sends RPC commands to the dcrwallet to steal all funds. It wouldn't be detected by virus scanners and as far as I'm aware would not require system administration or root privileges to perform those operations. It hasn't been done yet because Decred is still fairly new, and not particularly on the radar of people who write this sort of thing yet. I can promise you that it will be a viable, easy and cheap attack vector if Decred is to continue its current growth trajectory.
     
  4. David

    David
    Expand Collapse
    Full Member

    Joined:
    Jan 22, 2016
    Messages:
    313
    Likes Received:
    188
    Right... I never jumped on the virus bandwagon because most malware are obtained through user initiation, but this discussion does bring up some good points. Maybe the developers can look into creating a way to have the wallet online and able to send votes, but unable to send Decred until unlocked further. Casting a PoS vote is still a transaction that is generated and submitted to the miners, just like if you were to create a transaction to send Decred coins.

    I believe the current logic is that the wallet needs to be unlocked to generate any type of transaction. I don't see any security concerns with having a wallet that is locked and still able to generate voting transactions, but we'll have to hear the developers' input. While it sounds like a huge change to the core functionality of the software, It sounds like a step forward to me. I agree with your position that the vulnerability should be removed entirely so people don't have the chance to make a mistake.
     
    nullbio likes this.
  5. drunkenmugsy

    drunkenmugsy
    Expand Collapse
    Sr. Member
    Advocate (Reddit)

    Joined:
    Dec 28, 2015
    Messages:
    385
    Likes Received:
    214
    Dont run a wallet on your daily use PCs. Simple.

    RaspberryPi3s work great as PoS units in conjunction with a PoS pool. I ran into some missed tickets due to slowness on solo PoS RPi2s. Rpi3s seem better but more often than not(about 2/3rds) I get a "transaction already exists" notice on my RPi3 wallet daemon. Meaning the pool already cast a vote for me. RPi3s are relatively cheap as well. Currently you could get setup for under 5dcr.
     
    David and ClokworkGremlin like this.
  6. karamble

    karamble
    Expand Collapse
    Member
    Developer

    Joined:
    Feb 19, 2016
    Messages:
    57
    Likes Received:
    71
    there is a new Tool on its way called `promptsecret`

    it was included to the next decred-release on 31th march at github:
    https://github.com/decred/dcrd/tree/master/cmd/promptsecret

    So its allready in master you can just pull if you installed from source and give it a try.

    usage will be like
    Code:
    promptsecret | dcrctl --wallet walletpassphrase
    
    That you have to keep a unlocked wallet in order to cast votes is suboptimal, here i agree with you too. We are in need of walkttroughs in the documentations advanced section that shows how you set up a vote only wallet that actually never hold funds. That would solve the problem.Thanks for your thoughts, you are right!
     
    #6 karamble, Apr 2, 2017
    Last edited: Apr 2, 2017
    nullbio likes this.
  7. davecgh

    davecgh
    Expand Collapse
    Hero Member
    Developer Organizer

    Joined:
    Dec 31, 2015
    Messages:
    607
    Likes Received:
    749
    A minor clarification:
    Code:
    promptsecret | dcrctl --wallet walletpassphrase - 0
    
    You need the - to tell it to use stdin and how long to unlock it for.
     
  8. jcv

    jcv
    Expand Collapse
    Full Member
    Developer

    Joined:
    Dec 7, 2015
    Messages:
    183
    Likes Received:
    109
    promptsecret will be in the next release and dcrinstall will install it.

    That said, if your computer is not secure, nothing you run on it can be secure. There are operating systems like Qubes that do a lot of work towards isolating processes on your computer through VMs for this very reason. If you think your computer is compromised or will be compromised then application code can do little to help you.
     
    drunkenmugsy likes this.

Share This Page