Topic: more secure online processing (Read 1373 times)

cheers for the tips guys


my diagram is where the website top blue box never talks to the 'local computer' /home computer containing the wallet.
so it never has out going communications.. it just puts everything into data bases on website and the home computer reads it remotely.



my diagram offer the ability to withdraw.
simply by having a database on website side that stores withdrawal requests.
EG "user: xyd command: withdrawal amount: 2btc"


i have even thought of limiting what stuff would go into the database eg no addresses in the withdrawal request database, just a username and an amount so hackers cant just put withdraw 1mill BTC to adress 1lsssflsdflsdgobledegoop

and the home/local / hotwallet pc just accesses that database remotely and processes the commands as soon as they enter the database. and uses the verified address stored on home computer. so hackers cannot change the location.

the website never has ip addresses of the home PC listed or required. because the website never talks TO the home pc (no out going comms) just has incoming comms.

imagine it like ur the website. u write down a command onto a piece of paper "wife wants $5,000" and face it to a window.. me a home pc has a sniper scope pointed at you and reads the paper from a distance.. u cant see me but i can see you. anyone else who hacks in and reads your paper wont know ur wifes real name or where she is located.

i was thinking that the home computer that adds new addresses to the 'new deposit addresses' checks the addresses each time to compare them to the addresses saved in the hotwallet and sends the sql command to delete alien addresses from the website database. thus hackers might have 1 minute chance of adding a fresh address in before the database resets with just valid fresh addresses provided only by the hot wallet

I agree with the notion of not having a hot wallet inside the same hosting location. But ...

To me it looks like the hot wallet is linked to the Internet ? Anny server that holds a hot wallet needs to limit connections to specified local ip's and under no circumstances should it be talking directly to the Internet.  You need to keep it inside a local network with some type of proxy('s) and/or router(s) in between the protected data and the public.

Personally, for any medium to large scale service. I would add multiple proxy servers in to the mix to fully randomize the from and to traffic, think onion routing.


These services would not work under your construction, they all require data to go from the web service to the hot wallet (client). Why ? All these services offered the user the option to withdraw btc ... If you do not directly send the withdraw info to the client, the client would have to request and get access to it somehow, as a result these services need traffic back to the client.

So unless you add human interaction in to the mix ... and that would open a whole other can of worms.

People have been worrying at this problem since the invention of the web.

Basically it seems to come down to either web browsers are not cut out for this or some kind of plugin or extension or a new data type that fired up an external application to "display" it is needed.

Open Transactions for example plans to have a daemon aka "systray icon" on the user's end that all kinds of applications including browsers, instant messenger clients, videochat clients etc etc etc will talk to for any financial transactions. This encapsulates the finance stuff with all its rigorous security concerns from the normal day to day apps used to surf pr0n and download wares...

At the webserver end this would presumably just involve using some new kind of URL that tells the browser to fire up whatever application the user's desktop has been configured to use to handle that new, financial transactions oriented, type of URL.

-MarkM-

Your diagram looks pretty good, though falling back to another method of payment verification isn't a bad idea so your site doesn't break if you have to reboot your computer running the client.

Also, if the server is hacked the controlling party can supply forged deposit addresses, much lower impact but still problematic. Imagine if all of MtGox's BTC deposits went to someone else, even if only for a few hours.

One way I've thought to protect what would be the secret scripts on your diagram is to encrypt them and add a wrapper around them that required the decryption key as a POST parameter just to unlock such a script. To prevent a wrapper being placed around that to intercept the key it would need to verify itself and possibly some of the surrounding environment. Then the script would need to provide an appropriate response to confirm it's own identity. Messy, but if done correctly hopefully secure.

im just trying to understand the most secure way to impliment a webstore avoiding hacking and wallet theft.

is this flow diagram the basic best way to do it. totally avoiding using blockchain.info, bitcoinmonitor and other watch list services completely

Yup:


- http://acceptbit.com/

cheers for a wiki link with lots of jargon..

but ill start a list:
blockchain.info
bitcoinmonitor.net

any others?

Here's a wiki article with some suggestions:
 
 - http://en.bitcoin.it/wiki/Securing_online_services

im not going into discussions about specific websites.

back to topic at hand

setting up a more secure website to prevent hacking from stealing your coins by not having the wallet even on the hosting server.

anyone else got other suggestions how developers can avoid having wallets on hosting server. apart from using
watch only blockchain.info

BitFloor hasn't described many of the details regarding that security breach other than to say it was a "forgotten unencrypted backup".  So they may have had an adequately secured webserver with an inert wallet but were still left completely vulnerable due to poor security practices on a completely different system.

... hmm.. bitcoinica, bitfloor, intersango, to name just a few....

i dont assume no one does it. i just feel that it should be standard practice for all new developments to do this.

when reading developers making their retail webstores and/or exchanges, i see them making their home computers into webservers. which leads me to believe their wallet would be located on same IP address.. risky

and others use instawallet secret URL in their sourcecode which can easily allow hackers to send funds out of wallet.

easier and cheaper to just buy some secure hosting. and API call everything though a watch only blockchain.info.

atleast using the watch only method separates the hosting site from any hacks to gain private keys to transfer funds.

any other suggestions for safer methods to still allow hosting site instant information about payments without actually holding a funded wallet nearby?

Why do you assume nobody does that?

why does anyone have their webservice/shop URL as the webserver where their wallet is?

isnt it easier to just have some website code on a hosting site (even a free hosting site) not physically attached to their home webserver. which just API calls something like blockchain.info to validate payment received.

even easier to have the home webserver setting up deposit addresses and imports the addreesses to blockchain.info's watch only wallet.

thus as their are no actual funds in the blockchain.info (watch only) wallet. nothing can be stolen.

the hosting site uses the watch only blockchain.info wallet to grab those fresh address lists to display to new customers and then watches for a transaction received.

thus no actual interaction between hosting site and the 'offline' wallet (containing funds.)



shouldn't something like this be a standard practice to prevent hacking?

also the 'offline' wallet holding computer would not need to be set up as a webserver at all.. it would just need to API call the watch blockchain.info to update the watch only list of addresses.

i only use blockchain.info as an example. i think their are probably other ways of doing it