Bitcoin RPC Authentication Guide

Why RPC Authentication Matters

The RPC interface gives full control over your Bitcoin node — and potentially your wallet. Anyone with RPC access can send transactions, dump private keys, and shut down your node. Securing this interface is not optional; it's the most important security decision you'll make when running bitcoind.

Bitcoin Core supports two authentication methods: username/password pairs and cookie-based authentication. Both have their place depending on your deployment.

Cookie-Based Authentication

By default, Bitcoin Core generates a .cookie file in the data directory on startup. This file contains an automatically generated authentication token that changes each time the node restarts.

This is the simplest and most secure method for local access. Any process running on the same machine that can read the cookie file gets RPC access. Tools like bitcoin-cli automatically use this method when no credentials are specified.

The cookie file is located at: Linux: ~/.bitcoin/.cookie macOS: ~/Library/Application Support/Bitcoin/.cookie Windows: %APPDATA%\Bitcoin\.cookie

Cookie auth is ideal for single-machine setups where your application runs alongside bitcoind.

Username and Password Authentication

For remote access or multi-user setups, you'll need explicit credentials. The recommended approach uses the rpcauth option instead of plain-text rpcuser/rpcpassword.

Bitcoin Core ships with a Python script (share/rpcauth/rpcauth.py) that generates a salted hash:

python3 rpcauth.py myusername

This outputs a line like: rpcauth=myusername:salt$hash

Add this line to your bitcoin.conf. The advantage over rpcuser/rpcpassword is that the actual password never appears in your config file — only the hash.

You can create multiple rpcauth entries for different users, each with their own password.

IP Whitelisting

Always restrict which IP addresses can connect to your RPC port. By default, Bitcoin Core only listens on 127.0.0.1 (localhost). If you need remote access, explicitly whitelist only the IPs that need it:

rpcallowip=192.168.1.100 rpcbind=0.0.0.0

Never set rpcallowip=0.0.0.0/0 in production — this allows anyone on the internet to attempt authentication against your node.

For remote access, strongly consider tunneling through SSH or a VPN rather than exposing the RPC port directly.

Production Security Checklist

When running a Bitcoin node in production, follow these security practices:

Use rpcauth instead of plain-text credentials. Keep the RPC port behind a firewall. Run bitcoind as a dedicated non-root user. Use SSL/TLS for remote connections (rpcssl option or reverse proxy). Disable wallet functionality if not needed (-disablewallet). Monitor the debug.log for unauthorized access attempts. Set permissions on bitcoin.conf to 600 (owner-read-write only). Consider using a separate watch-only wallet for monitoring.

For the highest security, run your wallet on an air-gapped machine and use PSBT (Partially Signed Bitcoin Transactions) to transfer unsigned transactions between machines.