Feature request: "safe" API

[jl6]

The bitcoind server exposes all its features over the JSON-RPC API. This is somewhat dangerous in a production environment, as any system (e.g. a world-facing web server) which has API credentials has the ability to execute commands such as sendtoaddress. What I would like is the ability to start the bitcoind server in "safe" mode so that it only responds to whitelisted commands - such as getnewaddress and getreceivedbyaddress; with these two, you can offer a customer an address, and check it for payment confirmation later.

I understand that I could implement a wrapper around the API, but this feels like standard practice and something that the client should provide by default.

[error]

This is an issue and it certainly needs to be addressed.

In the meantime, don't run bitcoind on your public web server if you can avoid it. And make sure port 8333 is properly firewalled. And the system is otherwise properly secured.

[jl6]

Unfortunately even running bitcoind on a firewalled non-public back-end server is not sufficient if the public web server has the API credentials - any compromise of the web server would lead to full control of bitcoind.

A fully secure workaround is to pre-generate addresses on a secure system so that the private keys are only stored offline, then load them into a pool manually, in batches of, say, 1000 depending on how many orders you expect - similar to how you might run a one time pad encryption system.

Alternatively, you should at least operate a "No bitcoins stored on this server overnight" policy, whereby you transfer incoming payments to a "secure" address (i.e. private key stored offline) as soon as the payment is confirmed, limiting the scope of a break-in to very recent payments.

[twmz]

Unfortunately even running bitcoind on a firewalled non-public back-end server is not sufficient if the public web server has the API credentials - any compromise of the web server would lead to full control of bitcoind.

Use the encrypted wallet patch (which will hopefully be part of the core client sooner than later).  With it installed, the RPC credentials are sufficient only to do things that are mostly readonly.  Anything that requires access the a private key (i.e. sending BTC to an address) requires an additional encryption passphrase that you would not store but would get from the user interactively when it is needed.

[jl6]

Use the encrypted wallet patch (which will hopefully be part of the core client sooner than later).  With it installed, the RPC credentials are sufficient only to do things that are mostly readonly.  Anything that requires access the a private key (i.e. sending BTC to an address) requires an additional encryption passphrase that you would not store but would get from the user interactively when it is needed.

Wouldn't getnewaddress require write access to the wallet to save the newly-generated private key?

[twmz]

Use the encrypted wallet patch (which will hopefully be part of the core client sooner than later).  With it installed, the RPC credentials are sufficient only to do things that are mostly readonly.  Anything that requires access the a private key (i.e. sending BTC to an address) requires an additional encryption passphrase that you would not store but would get from the user interactively when it is needed.

Wouldn't getnewaddress require write access to the wallet to save the newly-generated private key?

Only if the key pool is empty.  When the key pool is not empty, getnewaddress takes one of the already-created-and-encrypted keys and returns its public key.

Of course the key pool can not be refilled without the pass phrase, but the patch tries to fill the keypool any chance it can get (e.g. when you send a transaction and have provided the passphrase).  There is also an explicit API to re-fill the keypool that can be used if it gets low and there have been no opportunities to re-fill the pool as part of some other activity.