Topic: JSON-RPC password - page 2. (Read 36535 times)
Digest auth is a fair bit harder to implement on both the client and the server side. It _should_ be using SSL and client certificates, but that's just a major PITA. Either that, or unix sockets.
Hmm.. shouldn't it be using digest auth instead of basic auth?
I usually wrap everything into SSL or IPSec anyway, but digest auth might keep noobs from getting pwned so easily.
I usually wrap everything into SSL or IPSec anyway, but digest auth might keep noobs from getting pwned so easily.
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.
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.
If you are using PHP+JSON+CURL you can easily specify the user/pass with a curl_setopt() line. The parameter is "CURLOPT_USERPWD".
Thanks for the basic auth patch. Before the patch I was using uid/gid firewall lines to limit the bitcoind to only my special users/IPs that ran various scraps of code on crontabs. I'll likely still leave those protections in and just add in the basic http auth as well.
Thanks for the basic auth patch. Before the patch I was using uid/gid firewall lines to limit the bitcoind to only my special users/IPs that ran various scraps of code on crontabs. I'll likely still leave those protections in and just add in the basic http auth as well.
Think a BC or two is deserved for that one - sent.
Thank you sir. - sent. Whilst putting some security in is a good idea, it appears the JSON-RPC PHP doesn't support basic HTTP authentication right now. It'd have to be hacked in. Is anyone else using similar libraries going to encounter the same problem?
Also, whilst we're on the subject is bitcoind only binding to the loopback interface?
The PHP library I'm using definitely supports HTTP Basic authentication. You just have to craft the URL right:Also, whilst we're on the subject is bitcoind only binding to the loopback interface?
http://username:password@localhost:8332/
Of course, you can specify the username and password as part of the URL
. Think a BC or two is deserved for that one - sent. Whilst putting some security in is a good idea, it appears the JSON-RPC PHP doesn't support basic HTTP authentication right now. It'd have to be hacked in. Is anyone else using similar libraries going to encounter the same problem?
Also, whilst we're on the subject is bitcoind only binding to the loopback interface?
The PHP library I'm using definitely supports HTTP Basic authentication. You just have to craft the URL right:Also, whilst we're on the subject is bitcoind only binding to the loopback interface?
http://username:password@localhost:8332/
Whilst putting some security in is a good idea, it appears the JSON-RPC PHP doesn't support basic HTTP authentication right now. It'd have to be hacked in. Is anyone else using similar libraries going to encounter the same problem?
Also, whilst we're on the subject is bitcoind only binding to the loopback interface?
Also, whilst we're on the subject is bitcoind only binding to the loopback interface?
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:
This can be solved by removing the newlines (and maybe '\r's) from result at the end of the Base64Encode function:
http://www.alloscomp.com/bitcoin/patches/bitcoin-svn-109-rpcbug-2010-07-25.patch
Code:
POST / HTTP/1.1
User-Agent: json-rpc/1.0
Host: 127.0.0.1
Content-Type: application/json
Content-Length: 40
Accept: application/json
Authorization: Basic YWJiYWJiYWFiYmE6aGVsbG93b3JsZGhlbGxvd29ybGRoZWxsb3dvcmxkaGVsbG93
b3JsZGhlbGxvd29ybGRoZWxsb3dvcmxk
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.User-Agent: json-rpc/1.0
Host: 127.0.0.1
Content-Type: application/json
Content-Length: 40
Accept: application/json
Authorization: Basic YWJiYWJiYWFiYmE6aGVsbG93b3JsZGhlbGxvd29ybGRoZWxsb3dvcmxkaGVsbG93
b3JsZGhlbGxvd29ybGRoZWxsb3dvcmxk
This can be solved by removing the newlines (and maybe '\r's) from result at the end of the Base64Encode function:
Code:
result.erase(std::remove(result.begin(), result.end(), '\n'), result.end());
result.erase(std::remove(result.begin(), result.end(), '\r'), result.end());
There's probably a more elegant solution, but that works for me. Here's a patch:result.erase(std::remove(result.begin(), result.end(), '\r'), result.end());
http://www.alloscomp.com/bitcoin/patches/bitcoin-svn-109-rpcbug-2010-07-25.patch
Gavin, no. I know my way around urllib2 so that's not a problem. I would like to see the option to disable password authentication in the bitcoin.conf. We really shouldn't be protecting (advanced) users from themselves.
I was just annoyed that to even start -server (albeit on my test client), I had to edit the config file and insert a password. I can always hack my version of Bitcoin to not require a password by default if that's what I want, but I don't like the fact that bitcoin completely fails to start when I put in "rpcpassword=" with -server. I think the right way to do it would be to warn users (perhaps with a popup box if the GUI is starting) but still start the other stuff, even if the RPC server won't start.
Running with a password only marginally improves the security for a lot of applications anyway, since that password will have to sit in an httpd-readable file for my web server to execute JSON-RPC commands. The only user that's ever been hacked on my server? httpd. It is an important step for machines with multiple users, though, as is allowing the port number to be changed.
I was just annoyed that to even start -server (albeit on my test client), I had to edit the config file and insert a password. I can always hack my version of Bitcoin to not require a password by default if that's what I want, but I don't like the fact that bitcoin completely fails to start when I put in "rpcpassword=" with -server. I think the right way to do it would be to warn users (perhaps with a popup box if the GUI is starting) but still start the other stuff, even if the RPC server won't start.
Running with a password only marginally improves the security for a lot of applications anyway, since that password will have to sit in an httpd-readable file for my web server to execute JSON-RPC commands. The only user that's ever been hacked on my server? httpd. It is an important step for machines with multiple users, though, as is allowing the port number to be changed.
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?
Yes, that's right, rpcpassword is only required if you use -server or -daemon or bitcoind (I just tested to be sure).RE: what if the programmer can't figure out how to make their legacy COBOL code do HTTP authentication?
Then I think another config file setting to explicitly turn off RPC authentication would be better than a magical "if you set a blank rpcpassword then that turns off authentication." But I wouldn't implement that until somebody really does have a problem or until we have more than one way of doing the authentication (maybe https someday...).
lachesis: is supporting HTTP Basic Authentication a problem for you?
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 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?
The password definitely shouldn't be required.
I strongly disagree; software should be secure by default, and running bitcoind without a password (or bitcoin -server) is definitely NOT secure.I just don't see somebody saying "Man, Bitcoin sucks because I have to add a password to a configuration file before running it as a daemon." I can see somebody saying "Man, Bitcoin sucks because I accidently ran it with the -server switch and somebody stole all my money."
The password definitely shouldn't be required. Also, the new code chokes on "rpcpassword=". If there's no config file, the config file doesn't contain an rpcpassword line, or it contains "rpcpassword=", the password should be disabled.
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.
OK, I did Python and PHP, and I added what I know about Java. Can somebody who has used Java JSON-RPC update the wiki page with a working example?
Gavin's changes look good. I think everything is complete. Here's a test build, please test it!
http://www.bitcoin.org/download/bitcoin-0.3.2.5-win32.zip
http://www.bitcoin.org/download/bitcoin-0.3.2.5-linux.tar.gz
http://www.bitcoin.org/download/bitcoin-0.3.2.5-win32.zip
http://www.bitcoin.org/download/bitcoin-0.3.2.5-linux.tar.gz
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.
I've updated the RPC wiki page for how the password stuff will work in Bitcoin 0.3.3.
One nice side effect: you can prepare for the changes now; create a bitcoin.conf file with a username and password and modify your JSON-RPC code to do the HTTP Basic Authentication thing. Old code will just ignore the .conf file and the Authorization: HTTP header.
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. I don't want to just duplicate the HTTP Basic authentication Wikipedia page.
One nice side effect: you can prepare for the changes now; create a bitcoin.conf file with a username and password and modify your JSON-RPC code to do the HTTP Basic Authentication thing. Old code will just ignore the .conf file and the Authorization: HTTP header.
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. I don't want to just duplicate the HTTP Basic authentication Wikipedia page.
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=
#else
fprintf(stdout, "Warning: rpc password is blank, use -rpcpw=
#endif
I've implemented it so that all the command-line options can also be specified in the bitcoin.conf file.
Options given on the command line override options in the conf file. But I need to do more testing, especially with the "multiargs" options like "addnode".
Options given on the command line override options in the conf file. But I need to do more testing, especially with the "multiargs" options like "addnode".
Jump to: