Security is a Shared Responsibility
Why designing for security requires thinking about platforms beyond your own
Last week, 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 people could buy and store BTC or ETH in a custodial wallet, 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.
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 CTO 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 people to easily use their service without having to let the platform custody 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 UX — 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 people to any more risk than if those people 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 okay to enter your private key on a website.
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 people 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 people that a request to enter their private keys can be legitimate increases the likelihood that those people 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 SSN 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/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.)
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 people to enter their private keys or upload their keystore files, but not okay for us to do so?” That’s a very 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 your keys.
Second, there’s a special role that wallet software/services play in this ecosystem. They are the agent that mediates people’s interaction with the rest of the cryptocurrency ecosystem and it is absolutely imperative that people are able to trust that their wallet is presenting accurate information to them and is behaving in accordance with their intent. As such, there is an incredibly high bar of trust that wallet developers must achieve before knowledgeable cryptocurrency users will consider interacting with 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 people 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.
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 people could be confident entering their private keys. The startup CEO suggested that their company might even create such a tool themselves 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 MEW-branded transaction signing widget. How would visitors to a site with the widget embedded know that it was a genuine MEW widget rather than a look-alike widget that would steal their private keys? “They can just do a checksum.” Well, to trust that a checksum is valid, the person 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 people 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.
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 crytocurrency ecosystem to help users develop an understanding and intuition for this by only asking people 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 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!
