"Private Key Not Leaked" Is the Most Dangerous Placebo: How to Choose Truly Reliable Encryption Products?
Written by: imToken
If a crypto product has never experienced a user private key leak, does that mean it is secure enough?
The answer is obviously not that straightforward.
As is well known, from late September to late October, the crypto industry underwent a particularly intense series of security tests. From global top centralized exchanges to established hardware wallet manufacturers, multiple far-reaching security incidents were successively exposed.
If you carefully review the official announcements following these incidents, you will notice a recurring statement: "there is no evidence that private keys were compromised," or "user private keys and mnemonics were unaffected."
But the entry point attackers seek might not lie with the private keys. When internal exchange permissions can be stolen, when third-party security products serve as springboards to access management systems, when hardware devices are implanted with malicious modules, or even when users' real names, contact information, and home addresses are exposed due to data breaches, merely emphasizing "private keys were not leaked" clearly fails to cover all the risks users face.
After all, private key security is only the starting point, not the endpoint, of crypto asset security.
This also means we need to reassess one issue: in today's crypto world, how should we really determine whether a product is genuinely safe and reliable?
I. How Do Attackers Bypass Private Keys, and How Are Assets and Data Compromised?
In a previous article, we mentioned that observing recent security incidents together reveals a clear trend: attackers do not necessarily need to directly breach cryptography or private keys themselves; instead, they may look for breakthroughs along the entire "chain of trust".
From employee endpoints and third-party security products to software supply chains, service containers, and even transaction authorization processes, any crack in any link could render an otherwise seemingly robust security system useless:
In the Bybit incident, attackers infiltrated a Safe developer's device through social engineering, obtained relevant access credentials, and subsequently controlled the frontend resources within Safe's wallet infrastructure;
In the Bitget incident, attackers exploited vulnerabilities in a third-party security product to obtain internal high-privilege credentials, then bypassed existing risk control mechanisms using forged withdrawal instructions;
In the latest Binance incident, the attack path likely began with the compromise of a DevOps engineer's laptop (however, Binance later stated that further investigation uncovered additional entry points, so the complete attack chain remains to be confirmed);
These three incidents respectively involve third-party wallet infrastructure, third-party security products, and internal development and operations environments.
This also explains why traditional cold wallets and multi-signature mechanisms cannot solve every problem, after all, what attackers truly exploit are precisely those trust links that can affect final transaction execution but have not undergone sufficient independent verification.
Ultimately, in centralized asset management systems, attackers do not necessarily need to directly obtain user private keys; as long as they can control transaction commands, approval workflows, or wallet execution systems, they may trigger unauthorized asset transfers.
Besides the asset execution chain, another type of risk is easily underestimated by ordinary users: data breaches.
In May 2025, Coinbase disclosed an insider data theft incident. Attackers bribed certain overseas customer service representatives, used their normal work privileges to access internal customer support systems, and stole some users' personal information, account details, and transaction-related data.
Coinbase stated that the incident did not result in the direct leakage of user passwords, private keys, or funds, but the attackers' purpose in obtaining this data was precisely to carry out targeted social engineering attacks later, impersonating official customer service to lure users into transferring assets.
The Keystone incident further illustrates that user data breaches can also impact the authenticity verification of hardware wallets.
On October 20, Keystone's official website suffered unauthorized access. According to subsequent disclosures, attackers exploited vulnerabilities in the website's third-party data monitoring tools to obtain some users' purchase records, as well as WebAuth keys used to verify device authenticity.
This means that even if a user's mnemonic and private key are not directly leaked, attackers could still use stolen verification keys to manufacture counterfeit devices capable of passing official authentication, forcing users to unknowingly use risky hardware wallets.
Furthermore, the device and supply chain security issues exposed by Ledger require manufacturers to absolutely prevent possibilities of devices being swapped, tampered with, or implanted with malicious modules during hardware production, certification, logistics, and sales.
While these issues appear to occur at different points in the product, they ultimately converge on the same outcome: users losing control over their own assets.
Therefore, the fact that private keys were not directly leaked does not mean the entire product's security framework remained intact, especially as the rapid advancement of AI continues to amplify these risks.
II. How to Determine Whether a Crypto Product Is Safe and Reliable?
Having understood these events, let's return to the actual question everyday users must face: if you want to choose a relatively safe and reliable crypto product, what exactly should you look for?
Compared to brand recognition, product features, and marketing promotions, imToken believes at least three dimensions deserve priority consideration.
1. Private Key Control: Who Actually Holds Control Over Assets?
This is the most fundamental and crucial question when evaluating the security architecture of a crypto product.
First, it is necessary to distinguish between two completely different models: custodial and non-custodial.
Taking centralized exchanges as an example, users typically manage their assets through an account system. After depositing, assets enter the exchange-controlled wallet system, where the platform records user balances via an internal account system and handles withdrawals, risk control, and fund management.
The advantage of this model is convenience; users do not need to manage private keys themselves, but it also means users must trust the platform's asset custody, internal permissions, and operational management mechanisms. If the platform experiences system failures, loss of internal permission control, or fund management issues, users may be unable to normally access or withdraw their assets.
Non-custodial wallets are different.
When users create a wallet, private keys are generated in a local environment and kept by the user themselves; the wallet primarily handles key management, transaction construction, and signing functions, while the actual asset records reside on the blockchain.
In terms of structure, there is a clear distinction between the two:
Centralized Custody: User → Platform Account and Permission System → Platform-Controlled Wallet → On-chain Assets;
Non-Custodial Wallet: User Holds Private Key → Wallet Provides Management and Signing Tools → On-chain Address Directly Controlled by the User;
This means the non-custodial model reduces the platform's role as an asset custodian and minimizes the steps where users must rely on a centralized platform to control their assets.
Of course, this does not mean non-custodial wallets are absolutely secure.
Users must back up their mnemonics themselves, protect device security, and be responsible for every transaction and signature. Once a mnemonic is leaked, or a user voluntarily signs a malicious transaction, assets can still be lost.
Therefore, when choosing a wallet, users should at least clarify three questions: Are private keys actually generated on the user's device, or by a server? Will private keys and mnemonics be uploaded to the service provider's servers? Do users truly hold signing rights, and can they recover their assets in other compatible wallets?
2. Data Privacy: How Much Information About You Does the Product Actually Collect?
The second dimension is privacy protection, which many users easily overlook.
When using crypto products, users may leave behind vast amounts of information, including email addresses, phone numbers, identity verification documents, device info, purchase records, shipping addresses, and even account balances and transaction histories.
Not all of this data needs to be collected by every product.
For example, centralized exchanges typically require identity verification due to account systems and compliance requirements, whereas a basic non-custodial wallet, whose core function is local key management and initiating on-chain transactions, does not need to collect users' real identity information in the same manner.
Most notably here is whether the product adheres to the principle of data minimization.
For instance, are users' real identities, contact information, device info, and on-chain addresses unnecessarily linked?
Once this data is centrally stored, attackers can more easily build complete user profiles, leading to the "$5 Wrench Attack." After all, no matter how strong the encryption algorithms are, they cannot solve the problem of attackers directly locating the asset owner (for further reading: "Web3 Wallets' 'Perilous Autumn': Understanding the Evolution of Crypto Security's 'Spear and Shield' in the AI Era").
3. Security Architecture: Are There Continuously Verified Security Mechanisms?
The third dimension is the underlying technical security capabilities of the product.
For software wallets, focus should be placed on private key generation, encrypted storage, transaction signing, and code security; for hardware wallets, further attention must be given to secure chips, firmware integrity, device authentication, and supply chain management.
However, regardless of the product type, there are some universal evaluation standards.
First, is the core code auditable? Open sourcing does not guarantee absolute security, but at least it allows external developers and security researchers the opportunity to review critical code.
Second, whether it has undergone independent security audits. You can check if the product collaborates with professional security firms, which modules and versions are covered by the audit, and whether identified issues have been resolved.
It should be noted that audit reports are merely security assessments at a specific time and within a specific scope, meaning the entire product does not become completely immune to vulnerabilities thereafter.
Third, whether vulnerability reward and continuous testing mechanisms are established, because security is not a one-time task. As products continuously upgrade and integrate new chains and third-party components, the attack surface constantly evolves. Therefore, the presence of public vulnerability reporting channels, bug bounty programs, and comprehensive version review and permission management mechanisms are all noteworthy indicators.
Finally, it is also essential to see whether the product maintains sufficient security transparency. For example, how quickly it discloses the scope of impact, root cause of attacks, recommended user actions, and patch progress following a security incident is equally an important standard for measuring whether a product deserves long-term trust.
Above all, security audits, open sourcing, hardware isolation, and bug bounties are not standalone talismans.
A truly reliable security system should be able to isolate risks locally as much as possible, so that even if an issue arises in one area, it will not easily escalate into a complete loss of user asset control.
III. How Can Web3 Products Build Long-Term Security Systems?
Returning to the wallet products themselves, taking imToken's security philosophy as an example, the core lies in enabling users to retain control over their assets as much as possible, while reducing the likelihood of private keys and sensitive information exposure through product architecture and continuous security reviews.
1. Non-Custodial Architecture: Ensuring Private Keys Are Truly Held by Users
Unlike platforms that require centralized custody of user assets, imToken adopts a non-custodial wallet architecture.
Under this model, when users create a wallet, private keys are generated locally and kept by the users themselves. imToken does not store users' private keys or mnemonics, nor does it control on-chain assets on users' behalf through a centralized account system.
Currently, imToken's software wallets use secure random number sources provided by iOS and Android systems to generate private keys locally, and its core code, TokenCore, has been open-sourced since 2018.
For the imKey hardware wallet, mnemonics and private keys are generated through a True Random Number Generator (TRNG) built into the secure chip, providing an independent hardware security foundation for key generation.
The significance of this design goes beyond simply giving users a mnemonic phrase.
More importantly, it reduces the necessity for service providers to access and centrally manage user private keys at an architectural level, thereby lowering the risk of directly impacting user asset control when platform servers, internal personnel permissions, or centralized custody systems encounter issues.
2. From Data Privacy to Code Audits: Security Extends Beyond Private Keys
The non-custodial architecture solves the asset control problem, but a wallet still must face security challenges brought by applications, servers, third-party components, and external interactions.
Regarding data privacy, imToken has publicly stated that the product uses development tools like Sentry and Firebase for error reporting and statistics, but does not collect sensitive data related to wallet security. This means that necessary product operation statistics and core security information such as user private keys and mnemonics must maintain clear boundaries within product design.
In terms of technical review, imToken has long collaborated with professional security firms like SlowMist to conduct security audits for software wallets, hardware wallets, and smart contracts.
Meanwhile, a dedicated internal security team reviews code permissions, version updates, and third-party dependencies, conducting black-box and white-box security tests before product launch.
Together, these mechanisms form a continuous security management system covering the entire workflow from key generation and storage to code updates, external audits, vulnerability discovery, and remediation, rather than relying solely on a single technology or one-time security certification.
3. Security Is Not About Never Being Attacked, But Preventing Risks from Easily Accessing Assets
For users who hold substantial crypto assets long-term, relying solely on everyday online devices may not be the most appropriate asset management method.
Besides using hardware wallets, imToken also supports transaction information transfer between offline wallets and watch-only wallets via QR codes.
Specifically, users can prepare an old mobile phone no longer connected to the internet, install imToken, create an offline wallet, and then collaborate with a watch-only wallet on another internet-connected device via QR code connections that support the ERC-4527 protocol.
When a user needs to make a transfer, the internet-connected device is responsible for constructing unsigned transactions and passing them to the offline device via QR code; after verifying the transaction details, the offline device completes the signature using its local private key and transmits the signed result back to the internet-connected device for broadcasting.
Throughout this process, the offline device's private key never needs to touch the internet. This effectively adds a layer of physical isolation to daily asset management workflows, reducing the likelihood of network attacks directly accessing the private key.
For users seeking further hardware-level protection, the imToken ecosystem also offers the imKey hardware wallet.
imKey utilizes Infineon SLE78 series secure chips. Its underlying M7893 secure controller platform has passed CC EAL6+ enhanced certification, supporting capabilities such as secure storage, secure boot, and true random number generation.
Meanwhile, imKey also provides verification mechanisms such as device binding codes, initial activation processes, and device activation status checks, helping users identify whether a device is in its expected state of use.
These measures are particularly worth understanding against the backdrop of recent Ledger and Keystone incidents. Hardware security relies not only on chips being sufficiently reliable, but also on considering device provenance, initialization processes, and authenticity verification.
Of course, device authentication mechanisms are not foolproof anti-counterfeiting guarantees; users should still purchase through official channels and carefully verify the device status upon first use.
Final Thoughts
Reflecting on a series of security incidents involving Binance, Coinbase, Ledger, and Keystone, we find that the security boundaries of crypto products are becoming increasingly complex.
What users now need to protect extends beyond mnemonics and private keys to include identity information, purchase records, device authenticity, and any sensitive data potentially exposed throughout the entire usage process.
For everyday users, when choosing a crypto product, it helps to ask yourself three questions first:
Who holds my private key? Do I truly possess asset control? What data does the product collect about me? Will this information be excessively collected, retained long-term, or handed over to third parties? How does it prove it is sufficiently secure? Does it possess auditable code, independent audits, and continuous security response mechanisms?
No product can promise absolute security.
But a crypto product truly worthy of long-term use should at least reduce unnecessary trust dependencies architecturally, lower user exposure at the data level, and continuously undergo review and validation technologically.
After all, in the crypto world, the ultimate goal of security is not to make users believe a certain brand will never encounter issues, but to ensure users always retain control over their own assets.