Four Security Strategies from the Wallet Theft Incident

The most enduring methods of safeguarding are often simple, intuitive, and easy to understand, with the fewest steps and minimal trust requirements.

Written by: Liu Jiaolian

Keplr's social login wallet encountered issues, resulting in the theft of assets from thousands of accounts, with the official explanation pointing to a vulnerability in the Web3Auth infrastructure. Most of the affected users did nothing wrong; they simply opted for convenience by using Google or Apple to create this wallet.

The specific cause of the incident has not been disclosed in detail. Companies are also shifting blame onto each other. Following this lead, Jiaolian conducted a brief study and compared the security strategies used by several typical wallets to identify potential issues.

First, let's use the traditional self-custody strategy for cryptocurrency as a reference benchmark, where users write down their mnemonic phrases on paper and keep them safe.

This strategy is straightforward: the key is in your hands, and no one else knows it. Its security boundary is you: don’t lose the paper, don’t take a photo, don’t tell anyone. The downside is that human memory is unreliable; fire, moving, or laundry can cause that paper to disappear. However, the advantage is that the risk is right there on that paper, visible and clear. When it’s clear, you know to pay 120% attention and guard it closely.

With this reference benchmark, let’s look at the private key custody strategies of several popular wallet apps in the industry today. Note that we are excluding centralized exchanges that directly hold all control rights; we are discussing strategies that manage mnemonic phrases without holding complete asset control.

First, let’s examine Uniswap Wallet’s approach: its strategy is relatively simple, encrypting the mnemonic phrase and backing it up to your own iCloud or Google Drive.

A string of ciphertext is stored on Apple’s servers, and the decryption password is in your mind. To recover, you need to log into your cloud account and enter the password specifically used to encrypt the mnemonic phrase, which is not the same as your Apple ID. The cloud service provider only has the ciphertext, which theoretically cannot be decrypted. The risk shifts to the account side: if your Apple ID is stolen, a verification code is intercepted, or a phishing site tricks you into giving away your password, any of these could allow someone else to access your backup. But at least the risk is still in a familiar place; the cloud account and password are things you use every day.

The only risk in the cloud is if Apple or Google’s storage service is hacked. Of course, this is also why it chose Apple and Google over other cloud service providers, as it trusts the security capabilities of these two giants more.

Next is the classic web3 wallet MetaMask (commonly known as the little fox wallet) with its social login. Its approach is much more complex: the encrypted mnemonic phrase is stored on MetaMask’s own servers, and the decryption key is split into several pieces and distributed to different server nodes; to recover, you need two things: a login credential from Google, Apple, or Telegram, and the password you set. Only when both are combined can the key be reassembled.

MetaMask specifically states that even if all servers are compromised, the attacker would only obtain fragments and would still need to crack your password. This is true, but it depends on the premise. During normal online recovery, the login credential is the first barrier, the server’s rate limit is the second, and the password is only the third; a weak password will not be immediately compromised. However, once the shard nodes are breached and the attacker obtains the fragments, they can perform offline brute force attacks on their own machine, bypassing the rate limit, at which point the password strength becomes the only line of defense.

Finally, let’s look at the scheme used by Keplr, which had the incident. The key is split into three pieces: one piece is on the user’s device, one is on the cloud server, and one serves as a recovery backup, reassembled with server participation after login. The design allows for any two pieces to reassemble the private key, but if both pieces are controlled by the same service provider, the threshold for the three pieces degrades to a single point of failure. Jiaolian intuitively feels that this incident likely occurred here, but the real situation will depend on further technical details disclosed by the vendors.

When comparing these four methods side by side, a counterintuitive pattern emerges.

From the first to the fourth, it appears that more locks, more components, and a more complex system are being introduced, claiming or promising that complex encryption strategies can enhance security. However, the risks that users can clearly see are actually decreasing. The key written on paper is known to be there; the ciphertext stored in iCloud is known to be with Apple; with the MetaMask setup, the ciphertext is on the server, fragments are on nodes, and the password is in your mind; you need to understand four roles to clarify it; by the time you reach Keplr, when something goes wrong, users don’t even know who to hold accountable.

On the other hand, as the complexity of the system increases, the attack surface exposed to hackers is also expanding. How can hackers not rejoice? Paper and pen have only one risk: being stolen or burned; iCloud backup adds a cloud account; MetaMask adds login service providers, shard nodes, and password strength; Keplr adds the entire infrastructure. With each additional layer, trust reliance is dispersed across more levels and links, rather than eliminating trust.

This diffusion of trust reliance could be fatal. A simple arithmetic: if one person manages the key, any error by that person leads to a system error; if two people handle it, any error by either person leads to a system error. Clearly, the likelihood of any one of the two making a mistake exceeds that of one person making a mistake alone. In a chain of links, reliability only decreases, not increases.

So why design it this way? Because in the first method, the likelihood of one person making a mistake is simply too high. Miswriting a word, losing the paper, or having a family member throw it away as waste paper—these things happen every day. Social login significantly reduces the user’s error rate, at the cost of introducing the risk of service providers. On paper, it may seem cost-effective, but the problem is that users cannot see or verify either of these probabilities.

The most ironic part is here. A solution that requires ten pages of documentation to explain why it is secure means that ordinary users have lost their ability to judge. They can only choose to trust, and trust is not security; it’s gambling.

Jiaolian cannot help but recall the words of Satoshi Nakamoto in the Bitcoin white paper: "When there is a possibility of reversal, the demand for trust spreads." Although Nakamoto was referring to online payment scenarios, the analogy to private key recovery, which is inherently a reversible process, will inevitably lead to a diffusion of trust demand.

And this diffusion itself signifies an expansion of the attack surface for hackers. Every link that requires trust is a potential entry point for hackers.

The methods that truly withstand the test of time are often simple, intuitive, and easy to understand, with the fewest steps and minimal trust requirements. Simplicity does not mean simplicity in a crude sense; it means leaving complexity in the implementation and leaving judgment to the user.

If a wallet cannot clearly state who holds the key, then its so-called self-custody and security are merely a marketing slogan. To truly own something, you must be able to point to it and say, "This is mine, and I am 100% sure it is there."