I quote the above because it was one of the few reactions I’ve seen so far that matches my level of alarm. Over the past couple of weeks there has been revealed three critical wallet bugs: Two with the Ledger Nano hardware wallets and one with the Coinomi desktop application.
For a quick overview, with steps you should take right now, if affected, please see our previous article.
I’ve been testing Bitcoin wallets since 2013, and a lot has changed over the years in app features, appearance, and coin support. At least one thing has remained the same, however:
Security flaws (including critical ones) happen to every project.
Better quality assurance processes and security audits can help a wallet developer reduce the number of critical bugs that make it to end-user products, but nevertheless, stuff happens.
I get that.
However, the Ledger change bug was unique, at least in my experience, for breaking the underlying security assumption I had about hardware signing devices:
That no matter how compromised the internet-connected host device is, and as long as the user is careful to match what’s showing on the device screen with his intended destination, there is no way a user with a genuine hardware device can be tricked into sending crypto to a different address.
This assumption is no longer—and apparently never was—valid.
I’m sure I’m far from the only one to assume this, …thus, my concern. The Ledger change bug is the first example of a software-only attack that could have been (and still could be for non-upgraded users) performed on host devices via a compromised Ledger Live or even through malicious web-based transaction software (similar to MEW or MyCrypto). The bug was demonstrated using a modified version of Mycelium and showed no evidence on the device screen, itself. Malicious versions of real wallets are far from uncommon, as Electrum experienced recently.
To be clear: This post is not about Ledger. I even defended Ledger last year against overblown claims of newly discovered vulnerabilities, and it is my opinion that the widely-reported 35C3 / Wallet.Fail hacks from December are impractical on a large-scale (though important for emphasizing the need for physical security).
While I am disappointed in the lack of attention this change bug has been getting and the way Ledger has buried the issue in their firmware announcement, I could see something similar happening to Trezor or KeepKey, and my reaction would be the same.
The Need For Codebase Diversity
In Your Storage Plan
I propose that, due to a better understanding of the limitations of hardware wallet security above and the continued expectation for critical bugs in wallet software in the future (as the Ledger Monero and Coinomi bugs also prove), further emphasis should be placed on:
Dividing your crypto storage across two-or-more wallets from different codebases / wallet developers
In the case of hardware wallets—which are the most popular form of “safer” non-custodial crypto security, this would mean using a Ledger and a Trezor, dividing your assets between them. Other examples: A Trezor and a Coldcard wallet or a Ledger and a KeepKey. Not a Ledger Nano S and another Nano. Not a Trezor One and Trezor Model T.
This works just as well for hot wallet users: Splitting funds between Coinomi and Exodus. Edge and BRD. Blockchain and Copay (all examples). Not between Android, iOS, and desktop versions of the same app. Note that hardware wallets still provide much better protection than any hot wallet.
Using a BIP 39 passphrase to create separate wallets where only one is active at a time
This is especially useful for the Ledger and Trezor devices which are designed to easily switch between different passphrases. By using a passphrase on top of a 12/24 word recovery phrase, you can generate a whole new set of keys that can only be accessed while that passphrase is applied.
Someone hypothetically affected by the Ledger change bug who had part of their assets in another wallet via passphrase would not have lost those passphrase-protected assets (at least, not until they loaded the passphrase and tried to spend from it).
Passphrases need to be used with great care, however: A single character mistake will prevent you from generating the right accounts, which means either committing to remember the exact passphrase or writing it down and dealing with physical security concerns, as with the main recovery phrase.
Exploring offline / air-gapped wallets as an option for diversity
Traditional cold wallets are also a valid option for diversity, especially if they offer a means to transact via cold-storage signing and separate broadcast. Offline wallets can be as simple as a separate recovery phrase generated on a hardware device, written down, then deleted from the device after loading with funds.
Better still are those projects like Armory or Electrum that will sign offline a transaction generated online, then carried back over to the online device for broadcast. These solutions require careful planning and diligence, however, and are more tedious to use and easier to mess up. This is why they’re usually the domain of the advanced user.
Still, keep things in perspective…
The most common reasons people lose crypto assets in my experience are not critical bugs, but:
User error - Using the wrong address, becoming a victim of fraud, blindly confirming payments, downloading malicious software or using a phishing site
Failing to make a backup, losing backups, or backups that are written down incorrectly; if you diversify your crypto storage between wallets, generate a new recovery phrase for each wallet and don’t forget the backups!
Keeping crypto assets on a custodial exchange, unless part of a well-thought-out strategy of diversified storage
This is an opinion piece and does not necessarily reflect the views of Athena Bitcoin Inc. or other members of its staff. The author takes all responsibility for any factual or typographical errors.