The foundation of the Web3 ecosystem is the wallet, an app or browser extension that lets users verify their web identities and authorize transactions. But using a wallet has always involved a steep learning curve. New users must learn to copy down their seed words and store them in a safe place, create a strong password to encrypt their keystore file, copy addresses accurately when sending funds, and other things they may never have to learn when using a Web2 app.<\/p>\n
If a new user wants to make onboarding more accessible, one option is to use a custodial wallet provider, such as a centralized exchange. But experienced crypto users will almost always caution them against this for a good reason. The world has witnessed centralized exchanges like Mt. Gox, QuadrigaX and FTX go bankrupt from hacks or outright fraud, causing some customers to lose all their funds due to using a custodial wallet.<\/p>\n
Because of this risk, many crypto users still see a noncustodial wallet backed up by a set of seed words as the only secure way for a user to protect their Web3 identity.<\/p>\n
But do users always have to choose between security and convenience? Or is there a way to combine a noncustodial wallet’s security with an exchange\u2019s convenience? <\/p>\n
A few Web3 companies are trying to create wallets that are easy to use but also don\u2019t require the user to place all their trust in a centralized custodian. Companies like Magic, Dfns, Kresus, Web3Auth, Immutable and others believe that a wallet can be just as easy to use as an email account, and secure enough to be trusted to protect the user\u2019s identity and funds. These companies are using different types of new wallet infrastructure to make this idea a reality.<\/p>\n
Here is a rundown of a few of the solutions used by wallet developers:<\/p>\n
Magic<\/h2>\n
One new system is the Magic software developer kit (SDK), produced by Magic Labs. It is a developer kit and wallet infrastructure that allows developers to create seedless wallets for users.<\/p>\n
Instead of storing the private key on the user\u2019s device, an encrypted copy is kept on an Amazon Web Services Hardware Security Module (HSM). The encryption is performed using a Master Key that cannot leave the HSM. All signing is done within the HSM, preventing the user\u2019s key from being broadcast to the internet.<\/p>\n
Magic wallets do not use passwords. Instead, when users first sign up for a magic wallet, they submit their email address to the Magic relayer. The relayer then sends a one-time use token to the user through their email. This token will only work if used by the device that sent the request and only for a limited time.<\/p>\n
The token is used to authenticate with Amazon Web Services when the user clicks a link within the email. The blockchain wallet account\u2019s private and public keys are then generated on the user\u2019s device and sent to the HSM. Magic Labs says they cannot see the generated private key, as it never goes to their servers.<\/p>\n
When users stop using their wallets and close their browsers, they can reopen their wallets by repeating the process. They submit their email address to Magic again and receive a new, one-time-use token. This time, after authenticating, they regain access to their wallet.<\/p>\n
Magic Labs has created a demo\u00a0showing<\/a>\u00a0how the system works. It appears to allow anyone to create a wallet without downloading a browser extension or copying down seed words. It also allows users to close out their browsers and return to their wallets later, logging into the same Web3 account again.<\/p>\n The demo currently only works on testnets such as Goerli, Sepolia and Mumbai.<\/p>\n A few different wallets have been released or are currently in development that use Magic. One notable example is the Kresus wallet, a mobile app that allows users to store and hold Bitcoin (BTC<\/a>), Ether (ETH<\/a>), Solana (SOL<\/a>), Polygon (MATIC<\/a>) and tokens from these networks. It also allows users to send crypto using .kresus domain names instead of crypto addresses.<\/p>\n Kresus was released in the Apple App Store on May 11. The team told Cointelegraph that an Android version would come later in 2023.<\/p>\n Immutable Passport is another example. It\u2019s an application programming interface (API) built by Web3 game developer Immutable. When participating games integrate their websites with Passport, it allows players to create wallets directly through the game\u2019s site.<\/p>\n Related: <\/strong>What is Immutable, explained<\/strong><\/a><\/em><\/p>\n Immutable told Cointelegraph that Passport wallets connect to the Immutable X network, a layer-2 Ethereum protocol, which allows players to store all of their Immutable gaming collectibles in one account, regardless of which game they initially signed up with.<\/p>\n Immutable recently implemented Passport as the default login method for its developer portal, and they plan to use it for at least one game\u2019s login page by summer 2023, the team said.<\/p>\n The Magic SDK does contain one known security flaw, which developers have taken steps to mitigate. Because it relies on email tokens to authenticate a user, an attacker can potentially gain access to a user\u2019s HSM by hacking into their email account and then requesting to authenticate from the attacker\u2019s own device. Once they\u2019ve got access to the HSM, they can authorize any transactions from the user\u2019s account.<\/p>\n For this reason, both Immutable Passport and Kresus plan to use two-factor authentication (2FA) as an additional layer of security in case a user\u2019s email account becomes compromised.<\/p>\n Wallets based on Magic do not have passwords, so they can\u2019t be hacked through the usual method of stealing and cracking a password hash.<\/p>\n Another new wallet infrastructure developers are often using is Web3Auth.<\/p>\n Web3Auth is a key management network that relies on multiparty computation (MPC) to make private keys recoverable. When users sign up for an account using Web3Auth, they generate a private key as usual. Then, this key is split into three \u201cshares.\u201d\u00a0<\/p>\n The first share is stored on their device, the second is stored by the Web3Auth network through a login provider, and the third is a backup share that should be stored on a separate device or offline. The third share can also be generated from security questions if the user prefers.<\/p>\n Because of the way multiparty computation works, a user can generate the private key and confirm transactions with only two of the three shares. This means the user can still recover their wallet if their device crashes or they lose their backup key. At the same time, the login provider cannot perform transactions without the user\u2019s permission since the provider only has one share. <\/p>\n The provider also cannot censor transactions. If the provider refuses to give the user their second share after they\u2019ve correctly authenticated, the user can generate their private key using a combination of the share stored on their device plus the backup share.<\/p>\n Related: <\/strong>Multiparty computation could offer increased protection for wallets<\/strong><\/a><\/em><\/p>\n On Web3Auth, the login provider share is further split into nine different shards and distributed across a network of storage nodes, with five shards being needed to reconstruct the provider share. This prevents the login provider from storing its shares on its own infrastructure.<\/p>\n Web3Auth has been integrated into several retail wallets, including Binance Wallet and a closed beta version of Trust Wallet. In the extension version of Binance Wallet, users can create wallet accounts using their Google logins. In the Trust Wallet version, Google, Apple, Discord and Telegram\u00a0are login provider options<\/a>, according to an official video from Web3Auth\u2019s Twitter account.<\/p>\n In either case, the user still needs to copy down seed words. However, the account can be recovered even if these words are lost, so long as the user still has access to both their device and login provider account.<\/p>\n Speaking to Cointelegraph, Web3Auth CEO Zhen Yu Yong argued that the transition to using multiple key shares in Web3 is similar to the evolution of 2FA on Web2 sites, stating:<\/p>\n \u201cUsernames and passwords in the early 2000s or late 1990s were incredibly easy to lose. Back then, we thought that financial applications would never be built on the internet.\u201d<\/p><\/blockquote>\n \u201cWith usernames and passwords, we eventually progressed into two-factor authentication,\u201d Yong continued. \u201cI think that\u2019s the same transition we\u2019re trying to push here […] Instead of using a single factor seed phrase, we\u2019re splitting this up into multiple different factors [\u2026] and doing it such that it\u2019s all your access points, so it\u2019s all still self-custodial.\u201d<\/p>\n Dfns, pronounced as \u201cdefense,\u201d is an MPC key management network that allows institutions, developers and end-users to create passwordless and seedless wallets. It holds each blockchain\u2019s private key as multiple shards spread among nodes throughout the Dfns network. <\/p>\n To authorize a transaction, the Dfns nodes must jointly produce a signature using each shard.<\/p>\n Unlike Web3Auth, Dfns does not keep a share of the blockchain private key on the user\u2019s device or as a backup. All of the shards are kept on the network itself.<\/p>\n The Dfns nodes use a protocol called \u201cWebAuthn\u201d to verify that a user has authorized a transaction. This protocol was created by the World Wide Web Consortium to allow users to log into websites without a password. On Dfns, the nodes are programmed only to sign a transaction with their shard if the end-user has authenticated using this protocol.<\/p>\n When a user registers for a website using WebAuthn, the site creates a private key on the user\u2019s device. This private key is not used in any blockchain. It only exists to allow the user to log in to the site. <\/p>\n The user is prompted to protect the key with a pin code or biometric lock when the key is created. On a Windows PC, this lock can be created through Windows Hello, which is part of the operating system, or through a separate device such as a mobile phone or Yubikey. On a mobile device, the lock is generated using the device\u2019s built-in security.<\/p>\n On a website that implements WebAuthn registration, the user does not need an email address or password to register. Instead, the device uses its own security system to identify the user.<\/p>\nWallets based on Magic<\/h3>\n
Security concerns with Magic<\/h3>\n
Web3Auth<\/h2>\n
Web3Auth wallets<\/h3>\n
Dfns<\/h2>\n
![](\"https:\/\/s3.cointelegraph.com\/uploads\/2023-05\/e43344c3-bd14-4118-8258-eafbbef81d75.jpg\")