Wallet security has always been a primary concern in the Bitcoin development community. Although no other payment system in existence grants you the same level of freedom and control over your money that Bitcoin does, at the same time it can also be its greatest weakness. If you lose your wallet, or the password to your wallet, there is (usually) no one who can help you recover it. If someone else gains access to your wallet (and your password) and steals everything, there is no way to reverse the transaction. This has all been known for the past four years, and great progress in security has been made, but many people do not realize that we still actually have a long way to go. Even if you take all of the standard security precautions, as the examples I am about to give will show, often a single mistake can undo all of your hard work and set you back tens of thousands of dollars. What this article will do is explore some of the more worrying examples of recent (and not-so-recent) losses and thefts, and what users and developers can do to protect themselves.
The Allinvain Theft
Because of the sheer amount of media attention that it received, arguably no list of Bitcoin-related security incidents is complete without this one. In June 2011, the Bitcointalk member “allinvain” lost 25,000 BTC (worth $500,000 at the time) after an unknown intruder somehow gained direct access to his computer. The attacker was able to access allinvain’s wallet.dat file, and quickly empty out the wallet – either by sending a transaction from allinvain’s computer itself, or by simply uploading the wallet.dat file and emptying it on his own machine. The solution to this is obvious: wallet encryption. In allinvain’s time, this was not so simple; one would need to use a generic encryption program (eg. ccrypt) to encrypt the wallet, and then every time one wanted to spend one’s funds one would need to decrypt the wallet, use it, and then encrypt it again. Today, the process is much easier; wallet encryption has been built in to BitcoinQt since version 0.4 in September 2011, and Electrum, Armory and MultiBit all have a similar feature as well.
The Stefan Thomas Loss
This next incident is also fairly ancient in Bitcoin terms, taking place in July 2011, illustrates how wallet security can also fail in the other direction. Bitcoin developer Stefan Thomas had three backups of his wallet – an encrypted USB stick, a Dropbox account and a Virtualbox virtual machine. However, he managed to erase two of them and forget the password to the third, forever losing access to 7,000 BTC (worth $125,000 at the time). Thomas’s reaction: “[I’m] pretty dedicated to creating better clients since then.”
The Evil Java Application
This event, and everything below in this list, is much more recent, taking place in 2013. As the victim himself describes it, “last night around 9PM PDT, I clicked a link to go to CoinChat[.]freetzi[.]com – and I was prompted to run java. I did (thinking this was a legitimate chatoom), and nothing happened. I closed the window and thought nothing of it. I opened my bitcoin-qt wallet approx 14 minutes later, and saw a transaction that I did NOT approve go to wallet 1Es3QVvKN1qA2p6me7jLCVMZpQXVXWPNTC for almost my entire wallet (2.07 BTC)” [~$300 at the time]. This time, the wallet was encrypted, but the attacker was much more clever. The Java application that the victim had opened had also asked for additional permissions, which the victim instinctively granted, unwittingly giving the malicious program the ability to read all of his keystrokes. The application simply waited until he started typing in his wallet password, recorded the password, and then immediately proceeded to decrypt and empty out the wallet.
The Blockchain.info Theft
A blockchain.info user lost 160 BTC (~$20,000) to an unknown attacker. This time, user was not careless in any obvious way; he wrote: “I use the blockchain.info wallet service to manage that address. My password was a random 18 character password with punctuation, upper/lower case etc. I had two-factor authentication with Google Authenticator turned on and a second password on the account that was a random 8 characters.” Rather, the problem lay with the blockchain.info mobile application. On the desktop, blockchain.info encrypts users’ wallets twice; the entire wallet with the main password, and the private keys themselves with an optional second password as well. On the mobile however, for convenience only the second layer of encryption is used. In a stock Android setup, this is not a problem; the sandboxing mechanism ensures that one application’s storage is not accessible by any other application. This user’s phone, however, was roooted. Rooting one’s phone allows the user to use powerful applications that tinker with low-level parts of the Android ecosystem, but it comes at the price of trust: any application to which the user granted root access could have potentially read the wallet file and sent it off, leaving the attacker free to crack the relatively weak 8-character second password on some kind of GPU, FPGA or cloud-based computing cluster.
The Costly Brainwallet Mistake
A Bitcoin user stored 90 BTC (~$10,000) in a brain wallet – an address that, along with its corresponding private key, can be generated from a memorized password. Brainwallets can be a very secure way to store one’s savings, as the information needed to recover the funds only briefly touches a computer once when the address is first generated. The problem with a brainwallet, however, is spending it. Seeking to spend 2 of his 90 BTC, this user generated the private key from his password, loaded it into the MultiBit Bitcoin client, and sent a transaction. He then deleted the MultiBit wallet file (since if the private key remained stored on a computer file it would not be much of a “brain wallet” anymore). However, this proved to be a fatal mistake. MultiBit had sent the 2 BTC to its intended destination, but it also sent the other 88 BTC to a newly generated “change” address. If he had been using MultiBit normally, this would have been fine; sending change to a new address is standard practice and improves privacy. Here, however, deleting the wallet afterward deleted the private key behind the new address, causing the 88 BTC to essentially be lost forever.
The Hidden MtGox API Key
A Bitcoin user had $480 cleared out from their MtGox account even with two-factor authentication installed. It appears that an attacker had managed to somehow get into the account before the two-factor authentication was added, created an API key, and then used that API key to withdraw from the account two weeks later once the sum had been deposited. This is not a security flaw on MtGox’s part; an API (“application programming interface”) key is a password specifically intended to be used by computer programs, and the point of two-factor authentication is for the second factor (eg. a one-time password sent via text message, or a Google Authenticator application on one’s phone) to be completely separate from the computer used to access the site. Thus, API keys must necessarily bypass two-factor authentication to be useful. The one thing MtGox could do is offer to clear all API keys when two-factor authentication is added or the password is changed.
So What Can We Do?
All of these attacks have their own specific countermeasures; to avoid Bitcoin wallet thefts, turn on wallet encryption; to avoid thefts from exchange accounts, use two-factor authentication (look for a “Google Authenticator” option in your exchange account’s security settings) and make sure to check for API keys that were created without your permission; to avoid attackers trivially bypassing both, do not give untrusted applications excessive permissions, even at the cost of convenience, and to avoid loss, create more backups, and check them regularly.
But looking at how even the more responsible Bitcoin users in the above list get hacked, these events clearly show that simply telling people to be more careful is not good enough. It does not seem particularly realistic to ask the average non-technical user, or even the average technical user, to never make a mistake. Thus, what we really need in wallet security, from both users and developers, is a change in paradigm. Rather than trying to continually patch up our digital walls in an effort to make them unbreakable, what need to recognize that any particular strategy used to secure one’s funds can always potentially be circumvented by a mistake on the user’s part, and a mistake is guaranteed to happen eventually. From that viewpoint, the only viable strategy is obvious: defense in depth, using multiple layers of security and granularity to ensure that no single attack can cause all of our funds to get stolen – or lost. Here are some basic tips that can help:
- Basic Online Service Security – here, the multiple layers of defense are already provided, although it is your responsibility to actually use them. If you are using an exchange, make sure to (1) have a secure password, (2) turn on two-factor authentication (look for it in the security settings, and install the Google Authenticator app on your phone here), (3) make sure the email account that your exchange account is registered with has a secure password and two factor authentication, and (4) make sure you have no unauthorized API keys if you are using MtGox, and turn API access off entirely if you are using BitStamp (and do the equivalent for any other exchange).
- Basic Computer Security – do not download or run applications from untrusted sources; the Web of Trust addon for Firefox Chrome is a highly recommanded tool that can warn you if you are entering a shady website. Consider uninstalling Java, or at least if you see a Java application asking for permissions train yourself to click “Deny”. Run antivirus scans frequently, and if you catch anything consider your entire operating system infected beyond repair and reinstall.
- Wallet Separation – keep a separate “spending wallet” and a “savings wallet”. Your spending wallet should be a medium-security, but high-convenience setup with only a small portion of your bitcoins stored inside, and your savings wallet, containing the bulk of your funds, should be optimized for security (against theft and accidental loss) alone. The highest level of security is storing the savings wallet completely separately from your main operating system – a USB Linux distribution, a paper wallet and a brain wallet (provided you are careful with it) are all valid options.
- Two-of-three Schemes – two-of-three schemes are a common way of simultaneously reducing the risk of both loss and theft by adding redundancy. The btckeysplit utility can be used to split up any private key (or potentially password) into N pieces, such that any K of them (but never just K-1) can be recombined to get the original input (you choose K and N; two out of three is the simplest and most popular), and multisignature transactions provide an officially supported, and more versatile, way of doing the same thing. The three pieces or keys should be placed in completely different locations; memorizing one, writing down another and keeping a third on your computer is a good combination, and you could also give a piece to a semi-trusted third party or friend.
Developers can also help – online wallets and exchanges should let customers voluntarily set low daily withdrawal limits, and a better user interface for two-of-three schemes is needed to make them more widely used. One interesting idea for a service would be an online wallet that signs multisignature transactions in exchange for some form of identity verification, essentially taking on the role of the semi-trusted third party described above.
There are also other developments now on the horizon; dedicated hardware USB wallets will soon come out, essentially providing a dedicated, highly secure mini-computer for making Bitcoin transactions that you can carry in your wallet. But just like wallet encryption and two-factor authentication, hardware wallets will only form part of a complete wallet security setup. In an increasingly digitized world, no technology will remove the need to make an effort to protect your digital keys, but users and developers alike can go a long way in making the Bitcoin world a safer place – users by always being mindful of security and taking advantage of the tips described above and developers by making it easier to do so.
