JSON-RPC password

View all posts

External link

I uploaded to SVN my changes to add a password to JSON-RPC.  If you're set up to build, please test it.

The -server switch is replaced with -rpcpw=<password>, which is also used with bitcoind.
bitcoin -rpcpw=<password>    -- runs with JSON-RPC port open
bitcoind -rpcpw=<password>   -- daemon with password

If you have a better idea for the switch name, let me know, but keep in mind there will eventually be a password for encrypting the database too.  I'm not sure but I think they may want to use different passwords for the two.

It gives a warning if you don't set a password.

All commands now require the password as the first parameter.  It'll tell you that if you run "bitcoind help".

The central code:

  // Check password
  if (params.size() < 1 || params[0].type() != str_type)
      throw runtime_error("First parameter must be the password.");
  if (params[0].get_str() != strRPCPassword)
      if (strRPCPassword.size() < 15)
      begin = strRequest.end();
      printf("ThreadRPCServer incorrect password attempt ");
      throw runtime_error("Incorrect password.");

Any comments on these decisions?

1) if (strRPCPassword.size() < 15) Sleep(50);  -- this means if it's a short password, it'll wait 50ms after each attempt.  This might be used as a DoS attack, but I figured if it's a short password, it's more important to protect against brute force password scan.  This may tell outsiders whether the password is less than 15 characters, but less than 15 isn't all that noteworthy, most passwords are less than 15.  If you want to close the DoS possibility, just use a password 15 characters or longer.

2) begin = strRequest.end();  -- if it's a single request with multiple invocations, I throw away the rest if one has a bad password.  This is so you can't stuff it with millions of password attempts in one packet.  What do you think, is this the right thing to do?  (multiple invocation is probably almost never used anyway)

I also fixed the two duplicated commands listed in the help:

getaddressesbylabel <pw> <label>
getbalance <pw>
getblockcount <pw>
getblocknumber <pw>
getconnectioncount <pw>
getdifficulty <pw>
getgenerate <pw>
getinfo <pw>
getlabel <pw> <bitcoinaddress>
getnewaddress <pw> [label]
getreceivedbyaddress <pw> <bitcoinaddress> [minconf=1]
getreceivedbylabel <pw> <label> [minconf=1]
help <pw>
listreceivedbyaddress <pw> [minconf=1] [includeempty=false]
listreceivedbylabel <pw> [minconf=1] [includeempty=false]
sendtoaddress <pw> <bitcoinaddress> <amount> [comment] [comment-to]
setgenerate <pw> <generate> [genproclimit]
setlabel <pw> <bitcoinaddress> <label>
stop <pw>
Right, that is quite a bit better. 

Can you give me any examples of other stuff that does it that way?  (and what the command line looks like)

The main change you're talking about here is instead of -rpcpw= when you start bitcoind, you'd use a switch that specifies a text file to go and read it from, right?  (any ideas what I should name the switch?)
So you drop a settings file in the ~/.bitcoin directory, that sounds better.  In the "no password is set" warning, it could tell you where the file is and what to do.

What is the most popular and common settings file format?

HTTP basic authentication should be considered.  In actual practice though, it's more work for web developers to figure out how to specify the password through some extra parameter in the HTTP or JSON-RPC wrapper than to just stick an extra parameter at the beginning of the parameter list.  What do you think?  Does HTTP basic authentication get us any additional benefits?  Moving it off the parameter list but then you still have to specific it in a more esoteric place I'm not sure is a net win.

I was confused for a bit because the password is given LAST on the command line, but FIRST in the JSON-RPC params list.  I agree that reading the command-line password from a file would be more convenient and more secure.
You're also confusing me, what do you mean?  Did I do something unintended?
Still need to know what's the most typical settings file format on Linux.  Is there a standard file extension?  I've never seen a settings file using JSON, and it doesn't look very human friendly with everything required to be in quotes.  I think what I usually see is like:
# comment

Is there a settings file thing in Boost?

When you're using bitcoind to issue commands from the command line as a client, can we have it get the password from the settings file then too?

Gavin pointed out I forgot to increment the column of numbers in CommandLineRPC, so the current -rpcpw= implementation doesn't work right from the command line with non-string parameters.  (JSON-RPC is fine)  Still under construction.
I was researching config file formats, here's a comparison.

YAML is massive.  I'm not sure there's a lightweight easy to build library we can integrate into our project.  Seems overkill.

JSON is tempting and I'm inclined to like it, but two main sticking points:
1) No comments!  How can you have a config file where you can't comment out a line to disable it?
2) Not very user friendly to have to "quote" all the strings, including the keys, and also have to remember the comma at the end of lines.
    "key" : "value",

I suppose we could easily preprocess JSON reading the config file one line at a time, truncate the lines at any # character (and/or "//"?), concatenate them into a string and pass it to JSON, so you could go:
# comment
"key" : "value",   # still have to remember the comma
"key2" : "value",   // comment like this or both

Boost has boost::program_options.

We could read lines ourselves and feed them into a map<string, string> mapConfig.

while (!eof)
  read line
  if '#' found, truncate line
  split line at first ':' -> key, value
  mapConfig.insert(key, value)

If we use the syntax:
# comment
key : value

...and don't allow whitespace indenting before the keys, I guess we would be a subset of YAML and could switch to YAML someday if we need more complexity.

If we go with self parsed, that doesn't mean we can't use JSON on particular parameter values as needed.  If an option needs a list or more structured data, it could always parse its value as json:
key : ["item1", "item2", "item3"]

Although it has to be all on one line then.

I guess I'm leaning towards self parsed mapConfig:
# comment
key : value
I just did a quick survey of 20 .conf files in /etc on my debian system, and found:
 1 file used "key value"
 5 used "key=value" 
Thanks for that survey!

I find "key value" a little unnatural.  There ought to be a more definite separator between key and value that suggests assignment.  The space people may just be getting lazy using their language's split function.
key=some full sentence with spaces in it.  # seems more clear
key some full sentence with spaces in it.  # than this

Allright then, lets go with self-parsed mapConfig, syntax:
# comment

file extension .conf.  What's the filename, is it ~/.bitcoin/settings.conf or ~/.bitcoin/bitcoin.conf or what?   

I think we better strip whitespace at the beginning and end of the key and the value.
# user who likes column formatted
k            = value
key         = value
longerkey =   this sentence would be this    # "this sentence would be this"
        key = value   # guess this is ok too
  nextkey = value
      right = justified

The normal syntax should be "key=value", but you can't blame people for the occasional "key = value".
boost::program_options has the same "key=value" format.  Gavin pointed out we can use it in a simple way as a parser without getting into all the esoteric c++ syntax like typed value extraction.  We can use more features if we want later.

Lets go ahead with HTTP basic authentication instead of password as a parameter.
TODO: dialog box or debug.log warning if no rpc.user/rpc.password is set, explaining how to set.
In many of the contexts of this RPC stuff, you can print to the console with fprintf(stdout, like this:
#if defined(__WXMSW__) && wxUSE_GUI
        MyMessageBox("Warning: rpc password is blank, use -rpcpw=<password> ", "Bitcoin", wxOK | wxICON_EXCLAMATION);
        fprintf(stdout, "Warning: rpc password is blank, use -rpcpw=<password> ");
Question for everybody:  should I add a section to the wiki page describing, in detail, how to do HTTP Basic authentication?  PHP and Python make is really easy-- just use the http://user:pass@host:port/ URL syntax.
Yes, I think that would be really good so each dev doesn't have to figure it out themselves.  We need a simple example for each of Python, PHP and Java importing the json-rpc library and using it to do a getinfo or something, including doing the http authentication part.
Gavin's changes look good.  I think everything is complete.  Here's a test build, please test it!
I don't think authentication should be disabled by default if there's no conf file or the config file doesn't contain "rpcpassword", but what if it contains "rpcpassword="?

I can see both points.

What if the programmer can't figure out how to do HTTP authentication in their language (Fortran or whatever) or it's not even supported by their JSON-RPC library?  Should they be able to explicitly disable the password requirement?

OTOH, what if there's a template conf file, with
rpcpassword=  # fill in a password here

There are many systems that don't allow you to log in without a password.  This forum, for instance.  Gavin's point seems stronger.

BTW, I haven't tested it, but I hope having rpcpassword=  in the conf file is valid.  It's only if you use -server or -daemon or bitcoind that it should fail with a warning.  If it doesn't need the password, it should be fine.  Is that right?
I found what appears to be a bug: with a long enough username and password combination, the base64 encoder in bitcoind produces authorization headers that look like this:
Authorization: Basic YWJiYWJiYWFiYmE6aGVsbG93b3JsZGhlbGxvd29ybGRoZWxsb3dvcmxkaGVsbG93
It inserts a newline every 64 characters, which obviously breaks the Authorization header, so commands like "bitcoin getinfo" fail. The server still works fine with properly behaving clients.

This can be solved by removing the newlines (and maybe ' 's) from result at the end of the Base64Encode function:
result.erase(std::remove(result.begin(), result.end(), ' '), result.end());
result.erase(std::remove(result.begin(), result.end(), ' '), result.end());
+1 to you for having such a long password that you found this bug.

Uploaded to SVN as rev 110.
i got some problems here too trying to get this run on PHP.
so far i had no luck, neither the wiki-sample (jsonRPCClient trying to fopen(http://username:password@localhost:8332/)), nor my curl-sample (using setopt CURLOPT_HTTPAUTH, CURLAUTH_BASIC) seem to work.
That's strange, didn't someone just say that was supposed to work?  (what library was he using?)  Post if you figure out what wrong.

I hope it's not going to put up this much of a fight for all PHP users.

Looks like we've got the Fortran scenario already.
Great catch!  Simpler fix is to specify the BIO_FLAGS_BASE64_NO_NL in the rpc.cpp/EncodeBase64 function
SVN rev 111