They would have averted the whole thing had they just paid the fuck attention to rubyonrails-security and updated in January when the bug was announced: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-0156

Looks like they are missing a massive 1200 BTC and making just shy of 65 BTC a year in trading fees.

https://vircurex.com/Reports/2013-11.pdf

At the time bitcoin wasn't worth so much so trading out might have been more reasonable. The large increase in price has made the debt much more significant.

It's unfortunate that those that have deposited since then have subsidised those that withdrew after the hacks.

Blame ruby... Blame malleability Blame ...

I wish a real security expert would publish good practices for using crypto wallets

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.

If you have 100KLOC in a complex system, it takes 1 line to destroy the security of the entire application. Unless your procedures and good practices include each line being meticulously checked for security vulnerabilities then you're going to have security bugs. Generally the only way this happens is if the software is used by millions of people and can afford to have this kind of verification done. Random bitcoin exchange put up over the duration of 3 weeks is so far from this level that you can't even begin to define procedures and good practices.

Just don't trust random websites with your money unless you have some form of insurance. It's not a hard concept.

Except that a trade api should never be 100kloc. The key to securing services like this is to drastically reduce attack surfaces. A lot can be gained just from splitting the API up into multiple services and multiple levels.

The HTTP api that's accessible over the internet would not be able to connect to the database, instead it would perform its actions by making requests to multiple services, every service having the absolute minimum api endpoints required. A user creation service. A user details service. An authentication service. A trade submission service. A trades reading service. Each of these servers would run on different VM's, if the money is there, make that different hardware.

Where possible the data would be split into different databases, a trade database, a users database, a wallets database.

The different services would have their own login credentials to those databases, would not be able to even connect to databases they don't need, and their credentials on those databases would only allow them to execute the queries that they need to do. (If a database you use does not allow for fine enough access control the service would access the database through a middleware that does.)

If that seems like a lot of work, I bet you there are security professionals reading this laughing at it knowing this is just a sane basic architecture, and that I'm a rookie and they'd do a dozen more stuff.

My point is just: Even if there's a 100kloc in your system, it doesn't mean it's impossible to secure. Even a 100kloc system will have a limited attack surface that can be divided, and controlled.

A cool way of introducing some additional proofing of your system is to do what big-science researchers do. Have two teams develop the same services, preferably in different languages. Then have a middleware in front of your database that requires for every action the request be sent from both services, and that the request be identical. As a side benefit your service would be quicker to reveal bugs in production as well.

There is no magic bullet but there are bullets. Certain programming practices can dramatically reduce the risk, as can certain environments vs. others.

January 8th, 2013 - Multiple vulnerabilities in parameter parsing in Action Pack (CVE-2013-0156) https://groups.google.com/forum/#!topic/rubyonrails-security...

Hacked May, 2013. Blame the exchange's devs who didn't do security updates.

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.

Hear, hear! I agree.

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.

Here http://maxtaco.github.io/bitcoin/2014/01/16/how-jason-bourne...

Thank you but this is for running your own wallet not for running a payment receiving and sending system for thousands of customers.