They say, 'Not your keys, not your crypto'—but at what cost does the user safeguard their keys?
Self-custody wallets provide users with independent signing authority, the foundation of true digital ownership. But would you trust your crypto assets to a private key that could be exposed by malware or lost to a simple negligence? In web2, forgetting a password is frustrating; in web3, losing a seed phrase or having it stolen is irreversible. Even centralized exchanges with institutional-grade security struggle to safeguard assets—proving that custody is anything but simple.
Today, self-custody is only as secure as your private key. Managing one demands constant vigilance—scrutinizing every link, verifying URLs, interactions, emails. When basic tasks like remembering a 6-digit PIN challenges the users, the complexity of secure key management becomes a significant barrier.
Some popular alternative approaches include blaming the user for self-custody failures, leveraging federated MPC for distributed key generation, and introducing centralization risks. Also, spin up multiple wallets for different apps to isolate risks. Others rely on hardware wallets, requiring strict hygiene and minimal web interaction, effectively locking users out of the decentralized web.
The problem isn’t just safeguarding a 24-word seed phrase. It’s about navigating a multitude of attack vectors – phishing attacks, clickjacking, malware, impersonator websites, and the ever-present risk of user negligence.
Protected Self Custody
Providing self custody with protection against single point of failures, attacks that can be engineered, and user negligence makes wallets more secure. Silk’s 2PC wallet counters attack vectors by splitting the key shares between the user and a server or network, ensuring that two-party authorization is required for every transaction, without knowing about each others share.
This design minimizes the attack surface by splitting the key instead of storing it in local storage. Silk can also rotate key shares, invalidating the local share if needed. Transaction simulation and policy engines adds an additional layer of security, detecting and mitigating vulnerabilities from compromised dApps or user-side compromises.
Key Custody
While code vulnerabilities grab the spotlight, phishing and private key compromises remain hackers’ weapon of choice. CertiK’s H1 analysis highlights this trend, revealing persistent flaws in key management as the root cause of wallet insecurity.
Keys owned by the user provides full authorization, but makes them vulnerable and increases the cognitive load to keep the keys safe. While distributing keys can mitigate some risks, improper implementation of these systems can introduce new vulnerabilities. Native implementations of MPC or SSS can leave keys exposed during reconstruction, exposure to dApps, and reliance on centralized servers that create new points of failure.
Let’s look at some of the common wallet security issues within web3.
Browser Extension Based Wallets
Browser extension wallets are the most popular, but they come with security risks. These wallets store the private key in the local storage of the wallet extension, accessible through passwords or passkeys.
Some vulnerabilities include:
- Malware: They can compromise the device and therefore the seed phrase
- Seed Phrase Exposure: During wallet creation or import, seed phrases are susceptible to screenshot attacks and keylogging.
- Insecure passwords: Passwords used to safegaurd the seed phrase at rest are typically low-effort to crack
Embedded Wallets
Built to simplify user onboarding through social onboarding and iframes, these wallets sometimes trade UX for security. Some of the attack vectors include:
- Clickjacking: setting iframe to be transparent and guiding the user to click above sensitive buttons such as signing transactions or exporting private keys Man-in-the-Middle (MITM) Attacks on login: Malicious websites can intercept communication between the iframe and the main website during login via a fake iframekeys or authentication tokens. This risk is heightened by users’ inability to verify iframe authenticity due to UI separation from URL.
- Implementation Weaknesses: Private keys can be exposed through cache simulations, third-party cookie access, or OAuth token interception.
- Key Compromise Detection Failures: Even with key-sharing schemes, these systems often fail to detect breaches on the user’s side, leaving servers unaware of potential compromises.
- Cross-site scripting (XSS): A web application vulnerability that allows attackers to inject malicious scripts, potentially stealing private data. E.g EtherDelta XSS vulnerability
- DNS attacks e.g. BGP hijacking: Network-level attacks redirect wallet traffic to malicious servers, enabling interception or manipulation of sensitive operations. E.g klayswap incident.
- Malware: Device-level compromises, including keyloggers, clipboard hijackers, or other malicious tools, that steal credentials, tamper with wallet operations, or steal private keys. Often the root cause for other attacks,e.g Radiant’s multi sig exploit.
- Compromised account used for social login: Often through targeted attacks and leaked passwords. JWT based authentication are hard to decentralize, as nodes can steal keys with access to JWT.
- Compromised frontend: A hacked frontend can expose sensitive wallet interactions, such as leaking private keys or altering transaction details before submission.
- Compromised WaaS provider: A breach here, if relied on centralized key management without proper sharding or decentralization, allows attackers to reconstruct private keys and compromise all hosted wallets.
Multi Sigs
They are mostly used along with hardware wallets/browser extension by protocols to manage large funds or interact with smart contracts on behalf of the protocol. A classic example is a signer device gets compromised in such a way that the front-end e.g. safe wallet, displays legitimate transaction data while malicious transactions were signed and executed in the background. This is possible even when using a hardware wallet. E.g Exploits on Radiant and WazirX. The $10 billion honey pot of cross-chain multi-sigs exposes the risks of relying on multi-sigs.
Passkeys
Passkeys are cryptographic keys stored on user devices for secure and easy authentication. They have become popular in web2 for 2FA and logins for web3 wallet. While they are better than passwords and use secure enclaves for device bound security, they are not suitable for holding large amounts of assets. The key is backed up on iCloud for cross device usage, which can lead to the iCloud account being attacked, depending on the asset value being lucrative.
When passkeys sync across devices, they momentarily exit secure hardware enclaves. This creates a window for potential malware interception, during cross-device or cross-platform synchronization.
Fresh Perspective on Wallet Security through 2 Party Computation
MPC in practice is N/2-of-N (or maybe N/3 or 2N/3): there's a committee, typically shared across a large user set, which everyone trusts.
— vitalik.eth (@VitalikButerin) August 27, 2024
2PC is between two parties making a computation combining their private inputs, and it's trustless: the other side can't extract your data.
Why not MPC
MPC structures typically use a t/n threshold, where t nodes out of n can sign to execute a transaction (e.g., 3/5). This design could exclude the user from the signing process, allowing the network to operate without user involvement, making them vulnerable to collusion. Additionally, all users rely on the same shared committee, creating a centralized trust point.
While this model distributes key shares, it also faces scalability and performance challenges while running as a network. Communication complexity grows rapidly with more participants, and traditional MPC struggles to handle parallel transactions or large networks efficiently.
Why 2PC and 2PC MPC
2 Party Computation splits the private key between the user and the network. To simplify, the user holds one part and the server or network holds the other part, and the sum or product of these is the full private key. The security benefits are neither party can
- Reconstruct the full key on their own
- Learn about other party’s key fragment
- Sign transaction without the other parties
2PC opens the design space to deploy granular policy engines and transaction simulation, to cross check every transaction a user signs – similar to web2 finance, where every transaction is checked by the bank or financial intermediary. 2PC does just that, but with user sovereignity. In essence 2PC gives additional security to users against most attack vectors talked above, e.g. if the user key is compromised at device level, dApp is compromised, the user is tricked by malicious frontend, etc.
Security-First Approach for Access to a Decentralized Web
Most onboarding wallets prioritize UX, but as they grow to hold significant funds, the incentive for hacking them increases. Incorporating security as a core principle while building multiple moving parts can mitigate threats. While a security-first approach may slow adoption, it will ultimately enable resilient systems that make public key cryptography as accessible as email—without overwhelming users.