[RyanZAG]

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)

[xdocommer]

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.

[RyanZAG]

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.

[tinco]

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.

[tinco]

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.

[shabble]

https://en.wikipedia.org/wiki/N-version_programming

[api]

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