Getting a real security expert and swapping from Ruby to Haskell or something is not the solution - you can still have bugs. Most security bugs come from misunderstanding some layer of abstraction or failing to check permissions in all possible branches, etc. These bugs are usually small logic errors and are completely independent of the technology used to transfer algorithm to machine code.
There is no silver bullet. The only secure software is software that has been used by millions of people in millions of ways and been slowly but surely improved. This software will still have bugs to be found, but far less than something newly written.
EDIT: And unit tests are not the solution either - do you have a unit test to check for a timing vulnerability? I thought not... (Counting off one of the many ways I've heard to make secure software)
Like I said blaming software is not a legitimate excuse. And there is no silver bullet but there must be procedures and good practices that make it too demanding and hard where time + effort will be way greater then the reward.
There is no magic bullet but there are bullets. Certain programming practices can dramatically reduce the risk, as can certain environments vs. others.
There's not much to publish. If you can't view the source, and it doesn't run on your computer, and you can't easily migrate from one to another then you can't trust it and shouldn't use it.
While I'm not implementing a crypto currency exchange, I will still have to disburse float based funds over short periods of time. As the site code will be responsible for this, there exists a hypothetical opportunity for a bad agent to break in and siphon off those funds. I'm toying around with making it impossible to withdraw funds once they are deposited by a user. If funds were limited to penny value drips to keep instances running, the site could be made aware of larger transfers of value out of given addresses. If that was noticed by the system, another secret system could 'pull the plug' on the API tokens for the Coinbase API. I'll need Coinbase to implement token revokes in their API...
Better, if the code is Open Source, I can have more eyeballs on it to prevent such an eventuality. You can review my code here: https://github.com/StackMonkey. The pool controller is the one which will need to be closely scrutinized. The appliance can only watch incoming payments, so it's not really that venerable. I choose to make all this code Open Source because it will be in charge of customer funds and, more importantly, the infrastructure of the Internet.
Moving forward, I don't think it's a good idea to use anything hooked up to your Bitcoin float that isn't Open. Still, it's a choice people can make freely, even if it's a poor one. Education matters.
RyanZAG|12 years ago
There is no silver bullet. The only secure software is software that has been used by millions of people in millions of ways and been slowly but surely improved. This software will still have bugs to be found, but far less than something newly written.
EDIT: And unit tests are not the solution either - do you have a unit test to check for a timing vulnerability? I thought not... (Counting off one of the many ways I've heard to make secure software)
xdocommer|12 years ago
api|12 years ago
obsurveyor|12 years ago
Hacked May, 2013. Blame the exchange's devs who didn't do security updates.
FedRegister|12 years ago
kordless|12 years ago
For context, I'm implementing a compute exchange: https://www.stackmonkey.com/ - whitepaper: https://github.com/StackMonkey/xovio-pool/blob/master/whitep...
While I'm not implementing a crypto currency exchange, I will still have to disburse float based funds over short periods of time. As the site code will be responsible for this, there exists a hypothetical opportunity for a bad agent to break in and siphon off those funds. I'm toying around with making it impossible to withdraw funds once they are deposited by a user. If funds were limited to penny value drips to keep instances running, the site could be made aware of larger transfers of value out of given addresses. If that was noticed by the system, another secret system could 'pull the plug' on the API tokens for the Coinbase API. I'll need Coinbase to implement token revokes in their API...
Better, if the code is Open Source, I can have more eyeballs on it to prevent such an eventuality. You can review my code here: https://github.com/StackMonkey. The pool controller is the one which will need to be closely scrutinized. The appliance can only watch incoming payments, so it's not really that venerable. I choose to make all this code Open Source because it will be in charge of customer funds and, more importantly, the infrastructure of the Internet.
Moving forward, I don't think it's a good idea to use anything hooked up to your Bitcoin float that isn't Open. Still, it's a choice people can make freely, even if it's a poor one. Education matters.
lukasm|12 years ago
xdocommer|12 years ago