<p>The JSON-RPC was never intended to be open to the public, hence the required <code>rpcuser</code> and <code>rpcpassword</code>. For added security it should also be configured to either listen only to the loopback interface or the allowed IPs limited to a few trusted sources.</p>

<p>The wallet password is used to access the encrypted private keys, that's the reason everything involving either adding new private keys or signing with the private keys requires the wallet to be unlocked.</p>

<p><code>backupwallet</code> exports the keys in their encrypted form and therefore does not require the passphrase.</p>

<p>If you have to allow JSON-RPC access to untrusted users, put a filter in front of it.</p>

CC BY-SA 3.0
2013-01-05T13:47:13.700Z
2013-01-05T13:47:13.700Z
cdecker
<p>I was surprised I was able to back up my wallet over JSON RPC without requiring the wallet password (or even without a secondary backup-only password)</p>

<p>I'm concerned that this could create a DOS attack if the following were to occur</p>

<ol>
<li>A read-only wallet service is created to perform low-risk operations with the wallet</li>
<li>That low risk service is somehow exploited via a web front end, etc.</li>
<li>The background process (now in control of the attacker) issues the <code>backupwallet</code> command</li>
</ol>

<p>I think that can be a risk depending on a number of scenarios:</p>

<ul>
<li>The user can save the file with many different random names and fill up the drive (DOS attack)</li>
<li>The user can overwrite system files with a copy of the wallet (DOS again)</li>
<li>If previous files aren't overridden, and an error is returned, (due to duplicate file, locked file, etc) the attacker can infer information about the remote file system</li>
<li>If the system supports pipes, perhaps the wallet can be piped to another remote system (/dev/???)</li>
</ul>

<p>So I'm wondering if a separate, backup-only password should be created to address this issue.  Namely I don't want to use the "decrypt wallet" password.  </p>

<ul>
<li><p>Also I'd like to force that all backups go to a specific directory (and not any other drive/path)</p></li>
<li><p>Is this a good idea and if so, how should it be incorporated into the network?</p></li>
</ul>

CC BY-SA 3.0
2012-12-16T03:52:03.917Z
Come to think of it, the Stop() method should also have a password (separate from the JSONRPC account) IMHO
makerofthings7
CC BY-SA 3.0
2012-12-16T07:27:13.027Z
There are probably a hundred attack vectors if you are letting unfiltered access to submit JSON-RPC commands.  "backupwallet" is probably just the quickest.  Like you could cause degradation/denial-of-service by doing nonstop getnewaddress RPC command, for instance.
Stephen Gornick
<security><json-rpc><backup><wallet.dat><data-security>
Should a JSON-RPC user be required to use a password when backing up the wallet?
makerofthings7
# Should a JSON-RPC user be required to use a password when backing up the wallet?

(Asked by: username_0 on 2012-12-16)

I was surprised I was able to back up my wallet over JSON RPC without requiring the wallet password (or even without a secondary backup-only password)

I'm concerned that this could create a DOS attack if the following were to occur

1. A read-only wallet service is created to perform low-risk operations with the wallet
2. That low risk service is somehow exploited via a web front end, etc.
3. The background process (now in control of the attacker) issues the `backupwallet` command

I think that can be a risk depending on a number of scenarios:

* The user can save the file with many different random names and fill up the drive (DOS attack)
* The user can overwrite system files with a copy of the wallet (DOS again)
* If previous files aren't overridden, and an error is returned, (due to duplicate file, locked file, etc) the attacker can infer information about the remote file system
* If the system supports pipes, perhaps the wallet can be piped to another remote system (/dev/???)

So I'm wondering if a separate, backup-only password should be created to address this issue. Namely I don't want to use the "decrypt wallet" password.

* Also I'd like to force that all backups go to a specific directory (and not any other drive/path)
* Is this a good idea and if so, how should it be incorporated into the network?

**Tags:** security, json-rpc, backup, wallet.dat, data-security

> **Comments:**
> **username_0**: Come to think of it, the Stop() method should also have a password (separate from the JSONRPC account) IMHO  
> **username_1**: There are probably a hundred attack vectors if you are letting unfiltered access to submit JSON-RPC commands.  "backupwallet" is probably just the quickest.  Like you could cause degradation/denial-of-service by doing nonstop getnewaddress RPC command, for instance.  

---

## 1 answers

### Answer by username_2 on 2013-01-05. Score: 1

The JSON-RPC was never intended to be open to the public, hence the required `rpcuser` and `rpcpassword`. For added security it should also be configured to either listen only to the loopback interface or the allowed IPs limited to a few trusted sources.

The wallet password is used to access the encrypted private keys, that's the reason everything involving either adding new private keys or signing with the private keys requires the wallet to be unlocked.

`backupwallet` exports the keys in their encrypted form and therefore does not require the passphrase.

If you have to allow JSON-RPC access to untrusted users, put a filter in front of it.


---

