Author

Topic: How insecure is normal bitcoind? (Read 615 times)

hero member
Activity: 1316
Merit: 503
July 09, 2016, 11:22:52 PM
#5
Alright so if i cover the following:

SSH'ing into server = I can stop that with ssh keys and disallowing root login
Wallet.dat = Just have an unbrutable password
Bitcoind = restrict ip and cookie auth only

There shouldnt be anything else i should be worried about right?
Short of a zero day vulnerability in any software on the server, that's all you really need to be secure.

Side note, you will want to set up automatic backups and frequently back up the wallet.dat file to a safe location.

Alright, thanks for your help Cheesy
staff
Activity: 3458
Merit: 6793
Just writing some code
July 09, 2016, 11:08:38 PM
#4
Alright so if i cover the following:

SSH'ing into server = I can stop that with ssh keys and disallowing root login
Wallet.dat = Just have an unbrutable password
Bitcoind = restrict ip and cookie auth only

There shouldnt be anything else i should be worried about right?
Short of a zero day vulnerability in any software on the server, that's all you really need to be secure.

Side note, you will want to set up automatic backups and frequently back up the wallet.dat file to a safe location.
hero member
Activity: 1316
Merit: 503
July 09, 2016, 10:44:45 PM
#3
When running a (commercial) server that regularly calls to the bitcoind client to send/receive coins and create addresses.

How much more security can choosing to use mutli-sig addresses provide (e.g using bitgo)
You can get more security by using multi-sig but the main caveat is that send Bitcoin from the server is a major pain in the ass.

What risks do i face if i choose to just use a normal bitcoind client on my server?
You face an attempted attacks on SSH'ing into your server in order to steal the wallet.dat file (fixed by using a strong wallet password) and attempts to connect to the RPC server in order to spend Bitcoin from your server (fixed by restricting IP access, blocking port 8332, and using cookie auth instead of rpcuser and rpcpass).

What risks do i face if i choose to use a mutli-sig provider?
You rely on a service to continue to stay up and running. If they were to close down, API calls would need to be rewritten. It is a hassle to send Bitcoin from your server.

Alright so if i cover the following:

SSH'ing into server = I can stop that with ssh keys and disallowing root login
Wallet.dat = Just have an unbrutable password
Bitcoind = restrict ip and cookie auth only

There shouldnt be anything else i should be worried about right?
staff
Activity: 3458
Merit: 6793
Just writing some code
July 09, 2016, 09:28:34 PM
#2
When running a (commercial) server that regularly calls to the bitcoind client to send/receive coins and create addresses.

How much more security can choosing to use mutli-sig addresses provide (e.g using bitgo)
You can get more security by using multi-sig but the main caveat is that send Bitcoin from the server is a major pain in the ass.

What risks do i face if i choose to just use a normal bitcoind client on my server?
You face an attempted attacks on SSH'ing into your server in order to steal the wallet.dat file (fixed by using a strong wallet password) and attempts to connect to the RPC server in order to spend Bitcoin from your server (fixed by restricting IP access, blocking port 8332, and using cookie auth instead of rpcuser and rpcpass).

What risks do i face if i choose to use a mutli-sig provider?
You rely on a service to continue to stay up and running. If they were to close down, API calls would need to be rewritten. It is a hassle to send Bitcoin from your server.
hero member
Activity: 1316
Merit: 503
July 09, 2016, 09:21:55 PM
#1
When running a (commercial) server that regularly calls to the bitcoind client to send/receive coins and create addresses.

How much more security can choosing to use mutli-sig addresses provide (e.g using bitgo)

What risks do i face if i choose to just use a normal bitcoind client on my server?

What risks do i face if i choose to use a mutli-sig provider?

Jump to: