Dan Elitzer is the blockchain and digital identity lead at IDEO CoLab, an R&D network that explores the impact of emerging tech through cross-industry collaborations.
In this opinion piece, Elitzer explains why designing for security requires thinking about platforms beyond one’s own.
Recently I met with the founding team of a group building a project in the cryptocurrency space. They walked my IDEO CoLab colleagues and me through their web app, showing how users could buy and store bitcoin or ether in a custodial wallet, and then use those funds in a variety of ways. I noticed that they also had an option to enter a private key directly to make a transaction.
RED ALERT!
First rule of crypto: never, ever, EVER share your private key.
Seriously. Just don’t. (gif by IDEO CoLab)Corollary: Be extremely skeptical, if not outright suspicious, of any service or communication requesting your private key.
Having met with this team previously and knowing their impressive backgrounds, I asked – relatively calmly – why they were asking for a private key. The chief technology officer explained that they were implementing a MyEtherWallet-style tool for signing transactions in the browser, so the private key would never be sent to their server.
The intent was to allow users to easily use the service without having to let the platform take custody of funds, while also eliminating the friction associated with having to open up a separate wallet application to generate, sign, and broadcast a transaction. It removes a few steps – hooray for user experience – but does the shortcut really warrant the trade-offs?
I’m very sympathetic to the view that UX in the crypto world is horrible and there’s a need to get creative in exploring opportunities for simplification. And as the team pointed out, from a technical perspective, they would not be exposing users to any more risk than if those users entered their private keys on MyEtherWallet.
That’s true – they could implement the exact same open source code as MyEtherWallet. I trust that they would do this properly and I expect that some meaningful amount of their future users would be willing to trust them and feel secure entering private keys on this website.
However, my concern is not primarily whether they could securely implement in-browser transaction signing; as I said, I trust both their competence and their intentions.
What worries me more is that this gives the false impression, especially to those new to cryptocurrencies, that it is OK to enter your private key on a website.
Basic information hygiene
Most people are used to operating in the context where if a password is compromised, even for a bank account, usually the damage is at least somewhat reversible. Crypto is different: if you share your private keys, you lose everything. There is no recourse for getting back your stolen bitcoin, ether, or other tokens.
A secure, trustworthy service requesting private keys normalizes the concept of users sharing private keys with services that they use. This is bad.
Even if the company in question is trustworthy, it is a virtual guarantee that everyone buying, using, or participating in the cryptocurrency ecosystem in any way will at some point encounter a hacker or scammer trying to steal their money. Training users that a request to enter their private keys can be legitimate increases the likelihood that those users will fall victim to a scam in the future.
An analog to this is when a traditional financial services company calls a customer about an issue and requests that the customer provide data like their account number, address, or last 4 digits of their Social Security nunber before proceeding.
NO!
Do not train your customers to share information or attempt to conduct any account-related interactions on a phone call that the customer did not initiate him or herself!
(For anyone to whom this is news: please always, always, ALWAYS end such calls immediately and call back through a support line listed on the website of the company in question.)
A high bar of trust
During a deep conversation that revealed the team had given a lot of consideration to security and usability tradeoffs, the startup CEO asked, “Why is it okay for MyEtherWallet to ask users to enter their private keys or upload their keystore files, but not OK for us to do so?” That’s a fair question.
First, I would assume that the majority of people entering their private keys to use MyEtherWallet originally generated those private keys on MyEtherWallet with the intention of using them on MyEtherWallet in the future. If you already trusted a website or application to generate your keys, you’re not greatly expanding your attack surface by continuing to trust them when you go to use those keys.
Second, there’s a special role that wallet software and services play in this ecosystem. They are the agent that mediates the user’s interaction with the rest of the cryptocurrency ecosystem and it is absolutely imperative that the user trusts that their wallet is presenting accurate information to them and is behaving in accordance with the user’s intent. As such, there is an incredibly high bar of trust that wallet developers must achieve before knowledgeable cryptocurrency users will consider using them to manage their assets.
If the cryptocurrency ecosystem is ever going to develop in such a way that tokens are useful for applications beyond just investment or speculation, we’ll see hundreds, thousands, possibly even millions, of services built that include interactions where users need to generate signatures with their private keys. Expecting people to be able to discern whether they should trust a new service they encounter with their private keys is untenable.
Beware impostors
One suggestion a colleague of mine had was for MyEtherWallet (or another highly trusted service) to create a transaction-signing widget that could be embedded in other sites, so users could be confident entering their private keys. The startup CEO even suggested that the company might even create such a tool itself and publish it for others to use. While I applaud the sentiment of building something useful and sharing it with others, the problem is not one that can be solved in this way.
Let’s say MyEtherWallet did create a branded transaction-signing widget. How would visitors to a site with the widget embedded know that it was a genuine MyEtherWallet widget rather than a lookalike that would steal their private keys? “They can just do a checksum.” Well, to trust that a checksum is valid, the user would need to first know what a checksum is, then run it themselves. Any visual cue as to the validity of the widget or checksum could easily be faked.
Unless and until it becomes reasonable to assume that an overwhelming majority of users have their own agent software automatically verifying signatures and running checksum functions, using easily faked visual cues to signify security will only increase the vulnerability of your users.
We’re all in this together
It turns out that this wonderful, trustless future that so many of us are striving to create isn’t actually so trustless.
In fact, it’s not even trust-minimized.
It’s trust-specified: we need to be very specific about who we are trusting for what tasks. It’s incumbent on all participants in the cryptocurrency ecosystem to help users develop an understanding and intuition for this by only asking users for the bare minimum amount of trust and permissions that we need and pointing them to reputable services who follow best practices in security and disclosure for all other functions.
Our responsibility to our users does not end when they leave our site or close our app. Behaviors they learn from us – or that we contribute to normalizing – will guide whether and how they interact with the myriad of other services they encounter in the future. In an industry where user mistakes are frequently irreversible, it’s incumbent upon all of us to keep the aperture of user expectations as narrowly focused as possible on the least risky behaviors.
We can build a more secure and more user-friendly future for everyone, but only if we stay vigilant about security for our users across all services they interact with, not just our own.
If you have any good examples of nudging users towards more secure behavior or best practices for secure UX design, please share in a comment below.
Exposed password image via Shutterstock