How can I keep a Hot wallet secured ?

[BitCoinDream]

I am using online wallet (blockchain.info) as my hot wallet. As I understand, to run a hot wallet for automatic withdrawal I have to keep the wallet password in the server. The withdrawal URL requires it to pass in a plain text format...

Can someone suggest me, what is the best way to secure it ? As I can see, at any point of time, it is open to the server guys !!!

[1715486936]

1715486936

[medUSA]

I am not a tech guy. I am just trying to point you to a general direction. I have read from other threads that you should run the payment service on another server. The website server should send encrypted transaction details to the payment server, and you can review the transactions (optional) before execution.

[BitCoinDream]

I am not a tech guy. I am just trying to point you to a general direction. I have read from other threads that you should run the payment service on another server. The website server should send encrypted transaction details to the payment server, and you can review the transactions (optional) before execution.

Thank u for giving the explanation. I want to mention 2 points regarding this...

1. Manual review is always best, but for an automatic withdrawal system, we have very limited scope for that.

2. Payment system can be separated to another server, but ultimately that is also a web server and the server guys may snoop into that.

[TimS]

I am using online wallet (blockchain.info) as my hot wallet. As I understand, to run a hot wallet for automatic withdrawal I have to keep the wallet password in the server. The withdrawal URL requires it to pass in a plain text format...

Can someone suggest me, what is the best way to secure it ? As I can see, at any point of time, it is open to the server guys !!!

This is not accurate. The blockchain.info wallet is designed so that the encryption password is never sent to the server. In short, the encrypted wallet is stored on the server, and decrypted on the client side only. It's re-encrypted before sending it back to the server.

You have to trust that the server won't modify the code (web page/JS) to send the unencrypted wallet back to the server, but everything else requires no trust and is verifiable (it's possible to read the client code). This is more of a problem on a web-hosted wallet like blockchain.info than on an app like Bitcoin Core, Armory, or Electrum since a web server can swap out code any time, while the others have to be explicitly updated/installed.

Client-side malware could also steal your money in the brief time that it's unencrypted on your side (but this is a problem with any hot wallet, and is a big reason why cold storage is safer).

If you're still concerned about the security of your hot wallet, I'd recommend any desktop wallet from https://bitcoin.org/en/choose-your-wallet except MultiBit (I've heard that it can lose your private keys in some circumstances, and the creator doesn't seem concerned with fixing that major problem). I use Armory.

[BitCoinDream]

I am using online wallet (blockchain.info) as my hot wallet. As I understand, to run a hot wallet for automatic withdrawal I have to keep the wallet password in the server. The withdrawal URL requires it to pass in a plain text format...

Can someone suggest me, what is the best way to secure it ? As I can see, at any point of time, it is open to the server guys !!!

This is not accurate. The blockchain.info wallet is designed so that the encryption password is never sent to the server. In short, the encrypted wallet is stored on the server, and decrypted on the client side only. It's re-encrypted before sending it back to the server.

You have to trust that the server won't modify the code (web page/JS) to send the unencrypted wallet back to the server, but everything else requires no trust and is verifiable (it's possible to read the client code). This is more of a problem on a web-hosted wallet like blockchain.info than on an app like Bitcoin Core, Armory, or Electrum since a web server can swap out code any time, while the others have to be explicitly updated/installed.

Client-side malware could also steal your money in the brief time that it's unencrypted on your side (but this is a problem with any hot wallet, and is a big reason why cold storage is safer).

If you're still concerned about the security of your hot wallet, I'd recommend any desktop wallet from https://bitcoin.org/en/choose-your-wallet except MultiBit (I've heard that it can lose your private keys in some circumstances, and the creator doesn't seem concerned with fixing that major problem). I use Armory.

I guess u missed my point. I'm not concerned about wallet's internal security in this case. I'm concerned about how to secure the wallet access on my web server.

[BitSimple_Support]

I'm not concerned about wallet's internal security in this case. I'm concerned about how to secure the wallet access on my web server.

DO use dedicated servers (rented or collocation) in a secure reliable datacenter.
DO a clean install of operating system on all servers using IPMI or IKVM to ensure there are no datacenter backdoor.
DO use Principle of Least Priviledge in all your design decisions.
DO use strong credentials for server access (long random passphrases are good, but public key cryptography is better).
DO strengthen authentication by limiting authorization to IP addresses.
DO take advantage of multiple Ethernet ports to create a dedicated secure internal LAN.
DO require a VPN connection to VPN endpoint (hardware firewall or dedicated server) for remote access to the secure internal LAN.
DO isolate the hot wallet to single purpose server which is connected only to the secure internal LAN.
DO ensure all backups are strongly encrypted (AES-256 or equivalent) and stored offsite to prevent unauthorized access via backups.
DO ensure your public bitcoin node (not wallet) has a large number of connections to the network.
DO consider using additional listening nodes to provide a more complete view of the network.
DO use dedicated machine (netbook fits nicely in a safe) to process cold wallet transactions offline.
DO use RAID for redundancy and sign agreement with datacenter that failed disks are ship to you for verification and destruction.
DO authenticate transaction requests from the webserver to wallet server.
DO add heuristic analysis of transactions and halt the hot wallet on unusual activity (requests from honeypot accounts, a high number of requests, invalid requests).
DO use an intrusion detection system (IDS).
DO use encrypted wallet on hot wallet to prevent access after power cycle.
DO consider having the hot wallet power off (better safe than sorry) when unexpected activity occurs and ensure there is no possibility of lost keys in the event of sudden shutdown.

DO NOT allow public access to IPMI or IKVM.  Limit connectivity to secured internal LAN only.
DO NOT allow direct access to wallet server.  Limit access to the secure internal LAN only.
DO NOT use disks without whole disk encryption.  All your security can be bypassed by just pulling the disks from the server.
DO NOT use datacenter switches for your internal LAN.  VLAN is only secure if you have sole access to the VLAN settings.
DO NOT use a "trusted" third party to provide you Bitcoin transaction data.  You could be put on an inferior fork and never know it.
DO NOT use a Virtual Private Server unless it is running on your hardware.  A VPS you "control" on hardware someone else controls is nothing but the illusion of security (see linode hacks).
DO NOT rely on transaction id of unconfirmed transactions.  Match "payments" by receiving address and unique inputs.
DO NOT have receive payments directly to hot wallet to limit the damage if hot wallet is compromised.  Instead route all incoming payments to cold wallet (and manually load hot wallet as needed).

If all that sounds too hard well you shouldn't be handling digital cash.  The security measures taken by Bitcoin service providers should be comparable to what is taken by a bank or gold bullion depository.

[cp1]

You should use a wallet that doesn't require you to send the password in the url.  I think coinbase lets you use a key + secret.

[zhinkk]

Well you have the right idea, a "hot" wallet. Do not keep large amounts in there that you are not willing to lose. In addition, you're using blockchain which isn't inherently insecure but since it's a web service keyloggers and other things like malware extensions could do some nasty things so be careful of that.

[Rannasha]

2. Payment system can be separated to another server, but ultimately that is also a web server and the server guys may snoop into that.

The wallet-server doesn't need to run a regular web server stack. All it needs is a piece of software that listens to requests made by the actual web-server. You should be careful to apply proper authentication so that only your web-server can make requests. You can then really hammer down the security on the wallet-server, firewalls, encrypted disks, etc...

There will always be a risk of course. If an attacker gains access to the web-server, it can examine the protocol you use to submit withdrawal requests and forge a request. There is no way around that and still keep automatic withdrawals.

[gweedo]

Keep whatever you can lose in hot wallet. Also take some analytics, I know this is not security related but this can help you figure out what you should leave in the hot wallet. If most users withdraw $25 at most, then you know you will be fine to leave $100.

Also it is going to be hard to secure the server the server people have access to root or physical access. Not much you can do. Just make sure you have a script that sends anything more than your maximum hot wallet amount to an offline or completely under your control address.

[Baitty]

Just leave what you intend to spend in a short time period. if you are planning on purchasing something within a month for $60 then leave $70 just in case. Otherwise I can't really think of any good ways to prevent losing all your savings.

[AliceWonder]

A VPS you "control" on hardware someone else controls is nothing but the illusion of security (see linode hacks).

This also is how they got an image of the Silk Road server.

[BitCoinDream]

I'm not concerned about wallet's internal security in this case. I'm concerned about how to secure the wallet access on my web server.

DO use dedicated servers (rented or collocation) in a secure reliable datacenter.
DO a clean install of operating system on all servers using IPMI or IKVM to ensure there are no datacenter backdoor.
DO use Principle of Least Priviledge in all your design decisions.
DO use strong credentials for server access (long random passphrases are good, but public key cryptography is better).
DO strengthen authentication by limiting authorization to IP addresses.
DO take advantage of multiple Ethernet ports to create a dedicated secure internal LAN.
DO require a VPN connection to VPN endpoint (hardware firewall or dedicated server) for remote access to the secure internal LAN.
DO isolate the hot wallet to single purpose server which is connected only to the secure internal LAN.
DO ensure all backups are strongly encrypted (AES-256 or equivalent) and stored offsite to prevent unauthorized access via backups.
DO ensure your public bitcoin node (not wallet) has a large number of connections to the network.
DO consider using additional listening nodes to provide a more complete view of the network.
DO use dedicated machine (netbook fits nicely in a safe) to process cold wallet transactions offline.
DO use RAID for redundancy and sign agreement with datacenter that failed disks are ship to you for verification and destruction.
DO authenticate transaction requests from the webserver to wallet server.
DO add heuristic analysis of transactions and halt the hot wallet on unusual activity (requests from honeypot accounts, a high number of requests, invalid requests).
DO use an intrusion detection system (IDS).
DO use encrypted wallet on hot wallet to prevent access after power cycle.
DO consider having the hot wallet power off (better safe than sorry) when unexpected activity occurs and ensure there is no possibility of lost keys in the event of sudden shutdown.

DO NOT allow public access to IPMI or IKVM.  Limit connectivity to secured internal LAN only.
DO NOT allow direct access to wallet server.  Limit access to the secure internal LAN only.
DO NOT use disks without whole disk encryption.  All your security can be bypassed by just pulling the disks from the server.
DO NOT use datacenter switches for your internal LAN.  VLAN is only secure if you have sole access to the VLAN settings.
DO NOT use a "trusted" third party to provide you Bitcoin transaction data.  You could be put on an inferior fork and never know it.
DO NOT use a Virtual Private Server unless it is running on your hardware.  A VPS you "control" on hardware someone else controls is nothing but the illusion of security (see linode hacks).
DO NOT rely on transaction id of unconfirmed transactions.  Match "payments" by receiving address and unique inputs.
DO NOT have receive payments directly to hot wallet to limit the damage if hot wallet is compromised.  Instead route all incoming payments to cold wallet (and manually load hot wallet as needed).

If all that sounds too hard well you shouldn't be handling digital cash.  The security measures taken by Bitcoin service providers should be comparable to what is taken by a bank or gold bullion depository.

Sorry Gerald. No startup can follow all these u have said. This is simply not economic and I guess u did not follow yourself all the above at the beginning of BitSimple.

Anyways, thanks for the list. It'll be my guide in the long run...

[BitCoinDream]

You should use a wallet that doesn't require you to send the password in the url.  I think coinbase lets you use a key + secret.

I dont trust CoinBase itself !!!

[BitCoinDream]

2. Payment system can be separated to another server, but ultimately that is also a web server and the server guys may snoop into that.

The wallet-server doesn't need to run a regular web server stack. All it needs is a piece of software that listens to requests made by the actual web-server. You should be careful to apply proper authentication so that only your web-server can make requests. You can then really hammer down the security on the wallet-server, firewalls, encrypted disks, etc...

There will always be a risk of course. If an attacker gains access to the web-server, it can examine the protocol you use to submit withdrawal requests and forge a request. There is no way around that and still keep automatic withdrawals.

Keep whatever you can lose in hot wallet. Also take some analytics, I know this is not security related but this can help you figure out what you should leave in the hot wallet. If most users withdraw $25 at most, then you know you will be fine to leave $100.

Also it is going to be hard to secure the server the server people have access to root or physical access. Not much you can do. Just make sure you have a script that sends anything more than your maximum hot wallet amount to an offline or completely under your control address.

Thank you both. I wish Gweedo implements some send/receive API soon on APIcoin and offers a free version for N number of call per day, where N is a small no. adequate for start-ups.

[BitCoinDream]

Just leave what you intend to spend in a short time period. if you are planning on purchasing something within a month for $60 then leave $70 just in case. Otherwise I can't really think of any good ways to prevent losing all your savings.

I dont intend to spend anything from the HOT wallet. Some people will be depositing and some other people will be withdrawing. I will just get a % as commission for running the service. As both deposit and withdraw are real time process, it is difficult to accept the payments at a cold wallet, because then withdraw may hit a blank wallet.

[BitSimple_Support]

No startup can follow all these u have said. This is simply not economic and I guess u did not follow yourself all the above at the beginning of BitSimple.

Of course a "startup" can and should pay the costs associated with proper security.  A startup doesn't mean some guy writing code with a budget of $50.  The costs for a solid security infrastructure are a few thousand dollars for the first year.  You can either do security correctly or you can "do it on da cheap"; the latter has rather predictable results.