{"id":30086,"date":"2013-05-17T02:47:21","date_gmt":"2013-05-17T02:47:21","guid":{"rendered":"http:\/\/ci027cfe6fd00a2697"},"modified":"2025-01-29T18:03:38","modified_gmt":"2025-01-29T18:03:38","slug":"bitcoin-self-defense-part-i-wallet-protection-1368758841","status":"publish","type":"post","link":"https:\/\/bitcoinmagazine.com\/culture\/bitcoin-self-defense-part-i-wallet-protection-1368758841","title":{"rendered":"Bitcoin Self-Defense, Part I: Wallet Protection"},"content":{"rendered":"
<\/div>
<\/figure>\n

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.<\/p>\n

The Allinvain Theft<\/h3>\n

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 \u201callinvain\u201d lost 25,000 BTC<\/a> (worth $500,000 at the time) after an unknown intruder somehow gained direct access to his computer. The attacker was able to access allinvain\u2019s wallet.dat file, and quickly empty out the wallet \u2013 either by sending a transaction from allinvain\u2019s 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\u2019s time, this was not so simple; one would need to use a generic encryption program (eg. ccrypt<\/a>) to encrypt the wallet, and then every time one wanted to spend one\u2019s 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<\/a> in September 2011, and Electrum, Armory and MultiBit all have a similar feature as well.<\/p>\n

The Stefan Thomas Loss<\/h3>\n

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 \u2013 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<\/a> to 7,000 BTC (worth $125,000 at the time). Thomas\u2019s reaction: \u201c[I\u2019m] pretty dedicated to creating better clients since then.\u201d<\/p>\n

The Evil Java Application<\/h3>\n

This event, and everything below in this list, is much more recent, taking place in 2013. As the victim himself describes it<\/a>, \u201clast night around 9PM PDT, I clicked a link to go to CoinChat[.]freetzi[.]com \u2013 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<\/code> for almost my entire wallet (2.07 BTC)\u201d [~$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.<\/p>\n

The Blockchain.info Theft<\/h3>\n

A blockchain.info user lost 160 BTC<\/a> (~$20,000) to an unknown attacker. This time, user was not careless in any obvious way; he wrote: \u201cI 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.\u201d Rather, the problem lay with the blockchain.info mobile application. On the desktop, blockchain.info encrypts users\u2019 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\u2019s storage is not accessible by any other application. This user\u2019s phone, however, was roooted. Rooting one\u2019s 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.<\/p>\n

The Costly Brainwallet Mistake<\/h3>\n

A Bitcoin user stored 90 BTC (~$10,000) in a brain wallet<\/a> \u2013 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\u2019s 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 \u201cbrain wallet\u201d 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 \u201cchange\u201d 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.<\/p>\n

The Hidden MtGox API Key<\/h3>\n

A Bitcoin user had $480 cleared out<\/a> 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\u2019s part; an API (\u201capplication programming interface\u201d) 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<\/a> application on one\u2019s phone) to be completely separate from the computer used to access the site. Thus, API keys must nece
\nssarily 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.<\/p>\n

So What Can We Do?<\/h3>\n

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 \u201cGoogle Authenticator\u201d option in your exchange account\u2019s 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.<\/p>\n

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<\/em>. 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\u2019s funds can always potentially be circumvented by a mistake on the user\u2019s 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 \u2013 or lost. Here are some basic tips that can help:<\/p>\n