Four Security Strategies Viewed Through Wallet Theft

Keplr's social login wallet encountered an issue, with assets drained from thousands of accounts. Official sources have pointed the cause to an infrastructure vulnerability in Web3Auth.

Most of the compromised users did nothing wrong; they simply chose convenience at the time, creating the wallet using their Google or Apple accounts.

The specific cause of the incident has not been detailed yet. Manufacturers are also pointing fingers at each other.

Following this lead, Jiao Lian conducted some research, aligning the security strategies of several typical wallets side-by-side to examine potential issues.

First, let's take the traditional cryptocurrency self-custody strategy as a baseline: the user manually writes down the mnemonic phrase on paper and stores it safely.

This strategy is straightforward: the key is in your possession, and no one else knows it.

Its security boundary is entirely you: don't lose the paper, don't take photos of it, and don't tell anyone.

The downside is human memory is unreliable; fires, moving houses, or laundry accidents could easily cause that piece of paper to disappear.

However, its advantage is that the risk point is right there on the paper, visible at a glance and completely clear to you.

When something is so clear, you know to pay 120% attention to it and guard against it meticulously.

With this baseline established, let's now look at the private key custody strategies adopted by several popular wallet apps in the industry currently.

Note that we are excluding solutions like centralized exchanges that directly custody full control rights. We are discussing solutions that custody private keys or mnemonics without assuming complete asset control rights.

Let's start with Uniswap Wallet's approach: its strategy is relatively simple—it encrypts the mnemonic phrase and backs it up to your personal iCloud or Google Drive.

Ciphertext is stored on Apple's servers, while the decryption password resides in your mind.

To restore, you must log into your cloud account, then enter the specific password originally used to encrypt the mnemonic, which is separate from your Apple ID.

The cloud provider only receives ciphertext, which theoretically cannot be decrypted.

The risk shifts to the account side: stolen Apple IDs, intercepted verification codes, or phishing sites tricking passwords into submission—all could result in backups falling into others' hands.

At least, the risk remains in familiar territory; cloud accounts and passwords are things you use daily.

There is only one cloud-related risk: Apple or Google's storage services being breached by hackers.

Of course, this is precisely why it chooses Apple and Google over other cloud providers—relative trust in the security capabilities of these two tech giants.

Next is the social login feature of the most classic Web3 wallet, MetaMask (commonly known as the Fox Wallet).

Its method is far more complex: the encrypted mnemonic is stored on MetaMask's own servers, and the decryption key is split into fragments distributed across different server nodes.

Restoration requires two things: login credentials from Google, Apple, or Telegram, plus the password you set.

Only when both are combined can the key be reconstructed.

MetaMask has explicitly stated that even if the servers were entirely compromised, attackers would only obtain fragments and would still need to crack your password.

This statement is correct, but it depends on the premise.

During normal online restoration, login credentials serve as the first barrier, server-side rate limiting acts as the second, and the password is merely the third; a weak password won't be immediately breached.

However, once the fragment nodes fall, attackers obtaining fragments can perform offline brute-force attacks on their own machines where rate limits are ineffective, making password strength the sole remaining defense.

Finally, let's look at the scheme employed by Keplr, which was involved in this recent incident.

The key is split into three parts: one on the user's device, one on a cloud server, and one serving as a recovery backup that participates in reconstruction on the server after login.

In design, any two of the three fragments can reconstruct the private key. However, if two of them are actually controlled by the same service provider, the three-fragment threshold degrades into a single-point vulnerability.

Regarding this incident, Jiao Lian intuitively suspects the fault lies in this exact area, though the true circumstances will remain unknown until manufacturers disclose further technical details.

Placing these four methods side-by-side for comparison reveals a counterintuitive pattern.

From the first to the fourth method, it appears there are increasingly more locks, more components, and more complex systems, claiming or promising that sophisticated encryption strategies enhance security.

Yet, the risks users can clearly perceive are actually decreasing.

For the key written on paper, you know where it is; for the ciphertext saved in iCloud, you know it's at Apple's end; for MetaMask's setup, the ciphertext is on the server, fragments on nodes, and the password in your mind—you must understand four distinct roles before you can even explain it; reaching Keplr's stage, when incidents occur, users don't even know who to blame.

On the other hand, while system complexity continuously rises beyond users' comprehension, the attack surface exposed to hackers simultaneously expands.

How could hackers not feel secretly delighted?

Paper and pen carry only one risk: theft or burning; iCloud backups add a cloud account; MetaMask's setup introduces login providers, fragmentation nodes, and password strength requirements; Keplr's scheme adds an entire infrastructure layer.

Each added layer disperses trust dependencies across more levels and processes rather than eliminating trust altogether.

This diffusion of trust dependency can be fatal.

A simple calculation illustrates this: if one person manages the key alone, their mistake causes system failure; shift to two people handling it, and any single person's error triggers system failure.

Obviously, the probability that either of two people makes a mistake exceeds the probability of a single person making a mistake themselves.

In a series connection, reliability only goes down, never up.

So why design it this way? Because in the first method, the probability of a single person making an error is actually too high.

Miswriting a word, losing the paper, or having a family member discard it as trash—these incidents happen every day.

Social login significantly lowers the user error rate, at the expense of introducing risk from the service provider chain.

It may appear cost-effective on paper, but the problem is that users cannot see nor verify either of these probabilities.

The most ironic aspect lies here.

A solution requiring ten pages of documentation to justify its security means ordinary users have lost the capacity to judge.

They are forced to place their trust, and trust is not security; it is gambling.

Jiao Lian cannot help but recall Satoshi Nakamoto's line from the Bitcoin whitepaper: "Where there is the possibility of a reversal, the demand for trust spreads."

Although Satoshi referred to online payment scenarios, drawing an analogy to private key recovery—a process that is inherently reversible—inevitably leads to the spread of trust demands.

And this diffusion inherently signifies an expansion of the hacker attack surface.

Every step that relies on trust becomes a potential entry point for hackers.

Custody methods that truly withstand the test of time are typically simple, intuitive, and easy to grasp, featuring the fewest steps and minimal trust requirements.

Simplicity does not mean crudeness; it conceals complexity within the implementation while leaving room for user judgment.

If a wallet cannot clearly state whose hands actually hold the key, then its purported self-custody and claimed security are nothing more than marketing buzzwords.

To genuinely own something, the prerequisite is being able to point to it and declare, "This is mine," with 100% certainty that it is exactly there.

Join the official Coincamps community:

X: https://x.com/coincamps

Telegram: https://t.me/coin_camps