June 24, 2024

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.


  1. Steven Murdoch says

    I certainly agree with your point. Bitcoin takes the extreme position of having no dispute resolution, and so anything less than perfect software security risks disaster. Other payment schemes take different choices, such as Chip and PIN which has moderately good software security but frequently inadequate dispute resolution. Mobile payments may be even worse, with poor software security and the same dispute resolution procedures as Chip and PIN.

    Overall I think that one take home message is that when it comes to payment systems, the protocol, the implementation, and the dispute resolution procedures all need to be considered. This is a point we made in our paper “Security Protocols and Evidence: Where Many Payment Systems Fail”.

    • Implicitly speaking, Bitcoin has a dispute-resolution system, it’s just a really bad one. Any time there’s a fork in the block chain, the longest chain wins, which is pretty much a recipe (all other things being equal) for resolving disputes the wrong way.

      Does anyone think that exchanges dealing in Bitcoin or similar currencies will undergo the same evolutions that exchanges dealing in cash did over the past 200 years or so? Cash has very similar characteristics, and bank robbery used to be quite a profitable enterprise, especially in the 19th century and the first half of the 20th. It would be funny if the future of cryptographic currencies were to involve wallets sitting in cold storage, with a superstructure of transaction notices and air-gapped reconciliations.