Topic: The plain text password for JSON-RPC connections issue... (Read 1780 times)

Use micro services. IE, separation of functionality.

A typical application has three states, application, database, and bitcoin service. Generally, following the micro service system design, each one of these states should be located on a separate instance/server with local networking enabled.

In design, the application server should have access to the db server, but not the bitcoin server, the bitcoin server should have access to the db server, but not the application server.

Application >><< DB >><< Bitcoin

The bitcoin server should be configured with a listener to determine incoming transactions. These transactions would then be written to the db for use in the application. Outgoing transactions would be written to the db from the application server and processed via a cron with a set interval.

 Disable external networking on the DB / bitcoin server with the exception of your local ip and key. Make sure that both states that utilize the db have different permission and users. Application can only write to transaction out bitcoin table, while bitcoin can only write to transaction out. Be sure when out processing transactions you can check the flow of bitcoin for a user via a history table.

By configuring the application in this manner, you are removing direct access to your bitcoin server as it is not exactly front facing. This method will not prevent hackers, but it will help to mitigate them and secure your application. Additional steps and monitoring should always be implemented

It has to be stored in plain text or equivalent, otherwise the user would have to provide the password every time they ran bitcoin-cli or any other API client. If someone had root access to be able to sniff internal packets, they could also get the password by recording keystrokes.

Authenticating a local service with a shared secret stored in a file with restricted permissions is not uncommon, by the way; for example, the X11 protocol and MySQL (by default) work the same way. On some platforms, including Linux, it's possible to check the peer UID through a Unix-domain socket, but I imagine the developers want to minimize platform-specific code.

Why not specify a password hash instead? And then just check if the hash of the password entered matches the one in the config file? But in the end, if the password is submitted via JSON-RPC/REST as plaintext, packet sniffing on the computer would do the job just as well.

Yeah, you never know who's a lurking, or if you have other team members helping with administration, support, etc. I was thinking of potentially using a program to at least change the pw automatically and restarting the application/service daily. On a system that has a wallet, I usually have dummy information just in case. I'm probably too paranoid anyway hahaha... thanks though!

It's not really what you're looking for, but...

If they can read your plain text rpc password from the config file on the server, your bitcoins are already gone because they likely got the wallet.dat file. (Unless that's encrypted but seeing as how they are on the server now they should be able to lurk in the shadows until it's decrypted)

I'm wondering how others are dealing with the bitcoin-qt issue of the password for JSON-RPC connections being stored as plain text in the config file (or command-line). It sort of bothers me from a security perspective, so I was wondering how others are dealing with it or possible solutions to the issue. I know you can limit allowed-ip addresses and change the port, but not a big fan of ptp on disk. Suggestions, workarounds?

Thanks