|
Title: Security Patterns and Practices Post by: optimator on September 05, 2012, 02:50:28 AM I've read with much sadness the security breach at bitfoor. I've also read about other bitcoin security breaches. I've read these posts trying to understand the security failure. In most situations this information is lacking. I've been thinking about creating new bitcoin services, and security is always forefront in my mind.
I'd like to propose (perhaps a wiki entry?) a security best practices framework. Perhaps we could start with some simple use cases: a) I store bitcoins for multiple parties [should the bitcoins be stored in one wallet-one address, one wallet-multiple addresses, multiple wallets, etc.]; b) I store USD, EUR, etc for multiple parties [how should fiat currency be stored?]; c) I access wallets from my application [should the wallet be online, offline, encrypted, on a separate server, etc, etc ,etc] I would like some input from others about a framework (pattern) for creating secure bitcoin applications. If something like this already exists please point me in the right direction. Title: Re: Security Patterns and Practices Post by: LightRider on September 05, 2012, 04:14:05 AM Use bitcoin as it is intended to be used. Peer to peer, not centralized. Bitcoin is about an individual's ability to assert sole authority and control. Giving that up to someone else is entirely against the intended design.
Title: Re: Security Patterns and Practices Post by: chrisrico on September 05, 2012, 04:48:35 AM Use bitcoin as it is intended to be used. Peer to peer, not centralized. Bitcoin is about an individual's ability to assert sole authority and control. Giving that up to someone else is entirely against the intended design. Erm... Bitcoin was created so that you wouldn't have to trust a central authority with the management of the money supply, to hold your wealth, to transfer payments from one party to another... not to remove all trusted third parties altogether. Unless you've got a way to provide a high volume online exchange without any trusted third parties, in which case, go on... Title: Re: Security Patterns and Practices Post by: RandomQ on September 05, 2012, 05:39:19 AM I'd like to propose (perhaps a wiki entry?) a security best practices framework. Perhaps we could start with some simple use cases: a) I store bitcoins for multiple parties [should the bitcoins be stored in one wallet-one address, one wallet-multiple addresses, multiple wallets, etc.]; b) I store USD, EUR, etc for multiple parties [how should fiat currency be stored?]; c) I access wallets from my application [should the wallet be online, offline, encrypted, on a separate server, etc, etc ,etc] I would like some input from others about a framework (pattern) for creating secure bitcoin applications. If something like this already exists please point me in the right direction. I'm surprised by some of these hacks, Cold Wallets are a must. Hell I setup 5 Semi-Cold Wallets on a VM hosted on a RAID with Offline Storage with everything encrypted for $100 worth of bitcoins in each wallet. But I'm very paranoid by nature and my Background in IT kinda helps when I've seen alot of different security issues over the years. You only need one backdoor in your system to allow them to take everything. There are a couple of stickies floating around with some best practices for Consumer based usage of bitcoin. Title: Re: Security Patterns and Practices Post by: Mike Hearn on September 05, 2012, 11:19:25 AM Unless you've got a way to provide a high volume online exchange without any trusted third parties, in which case, go on... https://en.bitcoin.it/wiki/Ripple_currency_exchange Title: Re: Security Patterns and Practices Post by: World on September 05, 2012, 11:37:58 AM Unless you've got a way to provide a high volume online exchange without any trusted third parties, in which case, go on... https://en.bitcoin.it/wiki/Ripple_currency_exchange Title: Re: Security Patterns and Practices Post by: stevegee58 on September 05, 2012, 11:42:43 AM Erm... Bitcoin was created so that you wouldn't have to trust a central authority with the management of the money supply, to hold your wealth, to transfer payments from one party to another... not to remove all trusted third parties altogether. Unless you've got a way to provide a high volume online exchange without any trusted third parties, in which case, go on... BTC will come of age when there is no longer a "need" to exchange it for fiat currencies. I personally feel no such need. BTC was intended to be exchanged for goods and services between individuals. Title: Re: Security Patterns and Practices Post by: optimator on September 05, 2012, 12:40:58 PM @World - Thanks for the link. That's the great overview. I'm thinking more technical like an Information Security Policy type document or even PCI-type standards.
A simple example - I'm a merchant. I've rolled my own bitcoin payment gateway. Because I'm paranoid, I send most of my btc offline. Now a customer wants to return an item. He sends me the item and I need to send btc. Assume for the above example you want this to be automated - because your store is really really big (like bigger than your bedroom) you want the return / credit process to be automated. 1. What percentage of "hot" btc reserve should be kept? It seems to me that with all the statistical types around these parts a formulaic answer could be created. 2. How does the merchant application (the store) access the hot wallet to credit the btc back to the consumer? Is the wallet on the same machine? where is the passphrase stored? BONUS QUESTION Should the merchant encrypt the customers btc address as private information? Title: Re: Security Patterns and Practices Post by: justusranvier on September 05, 2012, 12:55:04 PM @World - Thanks for the link. That's the great overview. I'm thinking more technical like an Information Security Policy type document or even PCI-type standards. I would put the hot wallet on a different machine, hosted at a different physical location than the main site. The hot wallet machine could poll the site (to determine when a refund is needed) via a Tor connection to make it even more difficult to find its actual location.A simple example - I'm a merchant. I've rolled my own bitcoin payment gateway. Because I'm paranoid, I send most of my btc offline. Now a customer wants to return an item. He sends me the item and I need to send btc. Assume for the above example you want this to be automated - because your store is really really big (like bigger than your bedroom) you want the return / credit process to be automated. 1. What percentage of "hot" btc reserve should be kept? It seems to me that with all the statistical types around these parts a formulaic answer could be created. 2. How does the merchant application (the store) access the hot wallet to credit the btc back to the consumer? Is the wallet on the same machine? where is the passphrase stored? BONUS QUESTION Should the merchant encrypt the customers btc address as private information? The amount that should be kept in the hot wallet should depend on the average amount of refunds . Decide how often you want to manually move funds from the paper wallets to the hot wallet and move that much on the chosen interval (if a site is refunding 20 BTC/day on average, twice per day = 10 BTC every 12 hours). Title: Re: Security Patterns and Practices Post by: chrisrico on September 05, 2012, 05:10:23 PM Erm... Bitcoin was created so that you wouldn't have to trust a central authority with the management of the money supply, to hold your wealth, to transfer payments from one party to another... not to remove all trusted third parties altogether. Unless you've got a way to provide a high volume online exchange without any trusted third parties, in which case, go on... BTC will come of age when there is no longer a "need" to exchange it for fiat currencies. I personally feel no such need. BTC was intended to be exchanged for goods and services between individuals. And fiat currency is a widely desired good in today's world. |