DID and Asset Security (Part 1): Security Risks of Sending Assets Using .bit/ENS

Avoid using .bit/ENS and all other DIDs to send assets directly in wallets and exchanges.

At present, users can use .bit/ENS to replace complex blockchain addresses to send assets in mainstream wallets and some exchanges. This has indeed improved the user experience but also introduced additional security risks. We have communicated with some developers and found that only a very small number of developers have noticed this risk and taken corresponding measures in their product. In response, we issue this risk warning, analyze these risks in detail. We hope that our reminder can provide a safer Web3 environment for users.

Security Risks of Sending Assets Using .bit/ENS

The above diagram is a schematic diagram of the information flow when a user sends assets to vitalik.eth in a wallet. When the wallet detects that the user has entered vitalik.eth when sending assets, it will initiate a query request to the server to query the blockchain address corresponding to vitalik.eth. After receiving the blockchain address returned by the server, the wallet constructs the transaction for the user to sign, then broadcasts the signed transaction to the network to complete the asset transfer.

We call the server responsible for responding to query requests the API Service. It tries to stay in sync with the blockchain network, and whenever a new block is generated, it parses the block data, finds related transactions, and updates its local database accordingly. There are generally three sources of such API services: provided by .bit/ENS development teams; provided by third-party data service providers, such as Infura, and provided by wallets/exchanges themselves. For many wallet/exchange developers, they believe that using their own deployed query service has high security. However, we will analyze that, based on their operating principles, API services of any source have the same risks.

It should be noted that although we use the somewhat centralized term "API Service" here, it does not mean that systems like .bit/ENS are centralized. In fact, they are decentralized, and any developer can deploy their own "API Service" without obtaining permission from others.

The existence of the following risks may ultimately lead users to send assets to the wrong address:

1. Hackers attack the API Service and tamper with the returned results;

2. Internal personnel of the API Service commit wrongdoing and tamper with the returned results;

3. Internal program exceptions in the API Service lead to incorrect results being returned;

4. The blockchain node used for data synchronization within the API Service lags behind the blockchain network, causing the API Service's data to be outdated and thus returning incorrect results;

5. The payee's .bit/ENS is not renewed in time, and after it expires, it is registered by others and associated with a new address. The asset sender does not know this information, leading the wallet to obtain the wrong address.

We have not yet seen any public reports of asset loss due to 1 or 2. However, we believe that as long as users gradually develop the habit of using .bit/ENS to send assets and the value of sending assets through .bit/ENS becomes attractive enough, they will inevitably occur. The risks brought by non-subjective factors such as 3, 4, and 5 are also impossible to completely avoid. As the habit of using .bit/ENS to send assets is formed, it's only a matter of time before non-subjective factors cause asset losses.

In addition, when the API Service fails and cannot return any results, users will not be able to send assets through .bit/ENS. Although this situation does not result in asset loss, it does harm the user experience.

These risks seem to be unavoidable and may cause serious losses. Does this mean that we cannot use .bit/ENS in the scenario of sending assets? The answer is no. We believe that the risks mentioned above do not originate from systems like .bit/ENS themselves, but from the incorrect use of .bit/ENS. Changing the usage method not only avoids the risks mentioned earlier but also makes the asset-sending process even safer.

We will share our in-depth thoughts on this issue and showcase our new solution for it at the Hong Kong Web3 Festival 2023's "Web3 Financial Infrastructure: Digital Wallet and DID" session. If you have questions about the risks mentioned earlier or have further insights, please join our Discord channel to communicate with our development team.

Before wallets and exchanges adopt more advanced measures, we recommend users avoid using .bit/ENS and all other DIDs to send assets directly in wallets and exchanges.