In order for crypto to go mainstream, and start to be used on the level of entire communities, the interfaces need to become more user-friendly. The makers of these Web3 “wallets” used by the public also need to address some major security pitfalls that can affect millions of regular users.
Key Management
Today, most Web3 wallets have major security problems. One of them is allowing people to export their private keys, and scammers end up tricking them into sending those keys, revealing their private seed phrases, issuing you the seed phrase you’ll use, or learning the seed phrase through some services online, e.g. by simply reading your clipboard that may contain it.
Key Storage
When it comes to securing very valuable assets or decision making ability, people don’t need to resort to fancy cold-storage and hardware wallet solutions. They can split the keys into multiple components using techniques such as Shamir Secret Storage, and then keep them in N places. They can also write down their 12-word seed phrase on a piece of paper, tear it into 4 pieces and store them in 4 different places. For redundancy, and in case some of the pieces get lost or corrupted, they can write the same phrase on multiple pieces of paper, ending up with, say, 4 copies of each 3-word segment.
A better way to manage high-value accounts is to use the ControlContract we have developed. It not only supports multi-sig wallets (requiring M of N signatures) but also succession plans, such as when the group of people to sign transactions has disappeared and not been taking any actions for a while. Anywhere you’d use a regular end-user address, you can use a ControlContract instead, if your organization wants it to play a very important role with a lot of responsibility. It works with any of our other community applications.
Knowing what you’re signing
Another major vulnerability is that people don’t know what they are signing, when they call methods on a smart contract. The wallet simply tells them that some site is asking them to take an action. Not very informative. Here is what people see when they use UniSwap to buy ITR tokens with ETH, for instance:
There is emerging support for EIP 712, but that is for signing data, not directly signing transactions to post to the blockchain. This may actually be a good thing, though, because that data can be posted to a web service, which then executes the transaction under its own meta-transaction. The web service could work with the Gas Station Network to execute the transactions and reimburse gas from their own wallet. This means that end-users would be able to get started with issuing transactions, without buying ETH or MATIC first.
On the blockchain side, this requires the smart contract that will actually execute the transaction to support EIP 2771. It can’t just be used with any smart contract, but those which are specifically built to support a TrustedForwarder pattern. In the end, though, the interface is a lot less opaque for the end-user:
Voting on the Blockchain
We have been implementing EIP2771 in all our community applications. This is the solution we are turning to, when it comes time for users to confirm how they wish to vote in an election, for instance.
We used to think that, since people are willing to use banking apps on their phone to manage tens of thousands of dollars, they should be able to trust similar apps to cast a vote. But the threat model turned out to be different: people value their own money way more than they value a single vote. Therefore, the user interface has to force a user to verify that they voted for the specific choice they intended to. They must do it in an external app, like the ones they trust to transfer their token balances. Thanks to ERC712 and EIP 2771, people can now use a wide variety of crypto wallets to review what they’re signing, sign it, and then make sure it was properly recorded in a the blockchain or Merkle tree.