Bitcoin Forum
December 06, 2016, 08:07:18 PM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: [1]
  Print  
Author Topic: Feature request: "safe" API  (Read 735 times)
jl6
Newbie
*
Offline Offline

Activity: 4


View Profile
June 08, 2011, 02:48:08 PM
 #1

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.
1481054838
Hero Member
*
Offline Offline

Posts: 1481054838

View Profile Personal Message (Offline)

Ignore
1481054838
Reply with quote  #2

1481054838
Report to moderator
1481054838
Hero Member
*
Offline Offline

Posts: 1481054838

View Profile Personal Message (Offline)

Ignore
1481054838
Reply with quote  #2

1481054838
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1481054838
Hero Member
*
Offline Offline

Posts: 1481054838

View Profile Personal Message (Offline)

Ignore
1481054838
Reply with quote  #2

1481054838
Report to moderator
error
Hero Member
*****
Offline Offline

Activity: 574



View Profile
June 08, 2011, 11:43:36 PM
 #2

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.

15UFyv6kfWgq83Pp3yhXPr8rknv9m6581W
jl6
Newbie
*
Offline Offline

Activity: 4


View Profile
June 09, 2011, 08:19:40 AM
 #3

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
Hero Member
*****
Offline Offline

Activity: 737



View Profile
June 09, 2011, 12:06:21 PM
 #4

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.

Was I helpful?  1TwmzX1wBxNF2qtAJRhdKmi2WyLZ5VHRs
WoT, GPG

Bitrated user: ewal.
jl6
Newbie
*
Offline Offline

Activity: 4


View Profile
June 09, 2011, 01:01:46 PM
 #5

Quote
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
Hero Member
*****
Offline Offline

Activity: 737



View Profile
June 09, 2011, 05:30:16 PM
 #6

Quote
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.

Was I helpful?  1TwmzX1wBxNF2qtAJRhdKmi2WyLZ5VHRs
WoT, GPG

Bitrated user: ewal.
Pages: [1]
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!