bitcoind should use RPC cookie auth not user/password

[reardencode]

--rpccookiefile=<path> should be used to put the cookie file in a path that accessible with components that require bitcoind RPC access

[Kixunil]

You might also be interested in my article explaining why it's more secure. (Maybe not entirely relevant after hardening, but having more security layers shouldn't hurt.)

[nixbitcoin]

Sounds good to me. Any reason why we shouldn't switch over @jonasnick ? If you ACK I'll take care of it.

[jonasnick]

We should use RPC cookie auth where possible, but we'll still need user/pass for services that don't support cookie authentication (lnd, elementsd).

[Kixunil]

@jonasnick I achieved "middle ground" in my repo by using RPC cookie in the RPC proxy and having a user with fixed password and harmless permissions (public calls only). Kills two birds with one stone. :)

Of course, we should probably complain at those projects or make PRs.

[nixbitcoin]

Switching to cookie authentication doesn't make sense if we're not using it for every service. Otherwise the security-win is negligible, because attackers can still connect to bitcoind with the static password.

Let's wait what bitcoind's rpc whitelists bring before we try to finesse cookie authentication. If with bitcoin/bitcoin#12763 it's possible to give every service it's own rpc user/password and then restrict the users to public calls only, I think we should go that route.

[Kixunil]

@nixbitcoin it's a little bit more involved. The native RPC filtering helps with "public" (harmless) calls. However, there's no way to secure non-public ones, as the Bitcoin Core filtering feature doesn't support cookies.

If there's any service that doesn't support cookies, but requires more dangerous features (if I remember correctly, Eclair is such service), it's impossible to solve without adding cookie support into such service. However, if all your services satisfy at least one of these requirements:

• supports cookies
• uses harmless calls

Then the safe way is to give a cookie to the services which support it and use RPC filtering for the services which don't. If I understand it correctly, Core can't use both cookie files and passwords, so the only possible options seem to be:

• PR to Core
• btc-rpc-proxy - this is what I use and maintain