Bitcoin hacks and thefts: The underlying reason

Emin Gün Sirer has a fascinating post about how the use of NoSQL caused technical failures that led to the demise of Bitcoin exchanges Flexcoin and Poloniex. But these are only the latest in a long line of hacks of exchanges, other services, and individuals; a wide variety of bugs have been implicated. This suggests that there’s some underlying reason why Bitcoiners keep building systems that get exploited. In this post I’ll examine why.

Let’s step back for a minute and talk about how we keep buildings physically secure. Locks are the first thing that come to mind, but they’re only a small part of the picture. Physical security is not just preventive but also reactive and corrective. We have intrusion-detection systems and ways of going after criminals. In particular, stolen goods are difficult to convert into cash. In the absence of the state and the rule of law, locks by themselves would do little to keep buildings secure.

Software security is exactly like that. Keeping attackers out is only the first line of defense; companies spend as much on intrusion detection. As the Heartbleed bug demonstrates, we don’t have processes that will produce code that’s free of vulnerabilities given the practical constraints of software development. Relying on prevention alone, then, is simply not an option. But the extent to which practical security relies on detection over prevention may be surprising. For example, my colleague Joseph Bonneau has argued that authentication is becoming a machine learning problem. The upshot is that on many or most sites where security matters, stealing a password is not by itself sufficient to impersonate the user.

Perhaps most crucially for e-commerce, banks can reverse fraudulent transactions and law enforcement of digital financial crimes is relatively competent. As a result, stolen passwords and credit card numbers are worth only fractions of a penny on the dollar. Viewed in this context, the role of cryptography and access control is merely to raise the bar sufficiently for attackers so that the risk of getting caught combined with the diminished ability to monetize break-ins skew the economics in favor of the defender.

Bitcoin’s design destroys this delicate balance of prevention, detection, and correction, and puts the entire onus on preventive measures. [*] If an attacker breaks into a server containing private keys, he can steal the bitcoins immediately and irreversibly. Furthermore, a stolen bitcoin is still a bitcoin. [**] While there’s been talk of taint-tracking mechanisms to prevent thieves from cashing out, these haven’t materialized and there are fundamental technical and political difficulties with such proposals.

I suspect that developers of Bitcoin services who are responsible for security consistently and dramatically underestimate what it takes to build a secure Bitcoin service. Coding and operational practices that are perfectly adequate for building a typical e-commerce site turn out to be utterly inadequate for, say, a Bitcoin exchange. Going back to the lock analogy, developers think they need a door lock when in fact they need Fort Knox. And software security as a field has simply not matured to the point where we’re even capable of building systems that rely primarily on preventive technological mechanisms in the face of persistent, financially motivated adversaries.

This analysis suggests that Bitcoin businesses will continue to face a rocky future, considering that the state of software security will not improve overnight. This is why research into techniques like threshold cryptography is so important; these measures can help secure wallets even when the underlying environment is vulnerable. At the same time, perhaps the security needs of the Bitcoin ecosystem will finally provide the kick in the pants needed to improve coding practices, security reviews and audits, adversarial testing, and operational security to the point where we can build systems that are secure by design. If this happens, it will have a huge, lasting, positive impact on the overall state of Internet security.

[*] These differences seem to be largely inherent, but they can be mitigated a little bit by measures such as keeping bitcoins in cold storage.

[**] A recent paper led by Sarah Meiklejohn argues that it currently is difficult for thieves to launder large sums of bitcoins. If this changes, we can expect that the incentives will shift even further in favor of attackers.

Thanks to Joseph Bonneau and Ed Felten for reviewing a draft.