# cannot be used rpcpassword (or bitcoin.conf in general)
#13143
I spent hours trying to solve this bug and the solution was so simple. My rpcpassword in my bitcoin.conf file contained a ‘#’ character.
Prevent this from happening, by outputting this an error or warning when users run bitcoind.
Right now, you can have a # character as a password and it will work on the command line but will fail when you JSON-RPC.
I could reproduce this. The reason that this happens is that # starts a comment in .ini syntax, so the password gets truncated (ouch!). There seems to be no way to escape those characters, either:
However - rpcpassword is the old way, there is now the rpcauth mechanism that stores passwords in hashed format. This is more in line with modern password storage security and could in principle be used to work around this.
However, the script to hash the passwords, share/rpcauth/rpcauth.py currently has no way to specify a custom password, it will always generate a random password with 256 bit entropy. Which is more secure in any case… But doesn’t help with this specific issue :-)
Have also recreated this. Using bitcoin-qt at https://github.com/bitcoin/bitcoin/commit/57c57df86f14874cfc4b280e04a7f44b19839c26. bitcoin.conf:
0server=1
1rpcuser=someuser
2rpcpassword=some#pass
This does not work:
0curl -u someuser:some#pass -d '{"method": "getblockchaininfo" }' http://127.0.0.1:8332/
However this does work:
0curl -u someuser:some -d '{"method": "getblockchaininfo" }' http://127.0.0.1:8332/
Expected output:
0{"result":{"chain":"main",
1"blocks":284781,
2"headers":520824,
3"bestblockhash":"000000000000000151b374e81b6f3956db0ab62502bd0fa90d461a31200244f2",
4"difficulty":2621404453.064615,
5"mediantime":1391850295,
6"verificationprogress":0.1001564948409792,
7"initialblockdownload":true,
8"chainwork":"0000000000000000000000000000000000000000000015520d7cd30c40324dc2",
9"size_on_disk":17344013534,
10"pruned":false,
11"softforks":[{"id":"bip34","version":2,"reject":{"status":true}},{"id":"bip66","version":3,"reject":{"status":false}},{"id":"bip65","version":4,"reject":{"status":false}}],"bip9_softforks":{"csv":{"status":"defined","startTime":1462060800,"timeout":1493596800,"since":0},"segwit":{"status":"defined","startTime":1479168000,"timeout":1510704000,"since":0}},
12"warnings":"This is a pre-release test build - use at your own risk - do not use for mining or merchant applications"},
13"error":null,
14"id":null}
I’ve created #13146 to allow hashing a custom password in rpcauth.py, so that one can do:
0$ ./rpcauth.py foo '###'
1String to be appended to bitcoin.conf:
2rpcauth=foo:31aa1353c61d96d89215887fd2d299$3cbfbe3059bd25361eded622079d7948277a42ff18fa8ff3e8b4816d343e2c7f
3Your password:
4###
5$ echo "rpcauth=foo:31aa1353c61d96d89215887fd2d299$3cbfbe3059bd25361eded622079d7948277a42ff18fa8ff3e8b4816d343e2c7f" >> ~/.bitcoin/bitcoin.conf
6$ bitcoind -regtest -daemon
7$ bitcoin-cli -regtest -rpcuser="foo" -rpcpassword="###" -getinfo
Though I think I’ve now lost track why I wanted a # in the password so badly in the first place.
Though, I think silently dropping the post-#-part in non-hashed passphrase seems still something that should be fixed. Not sure how, … maybe by refusing to run with a such passphrase?
The problem (see the stack overflow link) is that boost has no way to give you the part after #, so it’s undetectable whether the password (or any other option value) was chopped or not.
The opportunity to fix this will be after boost::program_options is replaced with our own implementation (#12744).