DID and Asset Security (Part 2): .bit Alias - Safeguard your asset against fraud
Learn how .bit Alias help you secure your transaction.
In "DID and Asset Security (Part I): Security Risks of Sending Assets using .bit/ENS", we discussed the security risks of directly sending assets using a DID. We advised users to avoid using .bit/ENS or any other DID directly to send assets in wallets and exchanges. These risks may seem unavoidable and could lead to significant losses. However, does it mean that we cannot use .bit/ENS in sending assets? The answer is no. In fact, we only need to adjust the method we use DID, which can enhance the security of the transfer process.
Basic concepts
Before we begin, we need to understand some terms and what they mean:
.bit Account: A .bit account is essentially a data container for user sovereignty, with a globally unique and human-readable name. Once a user stores data in it, the application can read the data and provide services to the user.
.bit Alias: A .bit Alias represents a piece of data (such as a blockchain address). Once a blockchain address has been assigned a .bit alias, this alias can be used to display instead of the address in any context.
.bit Lookup: This refers to the process of querying data (such as a blockchain address) stored under a .bit account name. It is similar to the Domain Name Resolution concept in the Internet Domain Name System.
.bit Alias Lookup: This refers to the process of querying the .bit Alias of a piece of data (such as a blockchain address). It is similar to the reverse DNS lookup concept in the Internet Domain Name System.
The following diagram illustrates the process of .bit Lookup and .bit Alias Lookup:
How can .bit Alias make transfers more secure?
Fill in the missing part of .bit Alias required by applications when making transfers
As shown in the picture, in this mode, the asset recipient provides the address and the corresponding .bit Alias to the sender. When the sender sends the asset, they input the recipient's address. At this time, the wallet/exchange will initiate a .bit Alias lookup request to the API service to retrieve the result and prompt the user to "please complete the alias for the recipient address." After the user fills in the information, the wallet/exchange compares it with the retrieved result. The transaction will proceed only if the two match.
Verify .bit Alias for transfers required by applications when making transfers
For small transactions, the wallet/exchange can simply prompt the user with a message such as "The alias for the receiving address is satoshi.bit, please confirm if it's correct."
This is somewhat similar to how we conduct fiat currency transfers in the traditional banking system. We never worry about making mistakes when transferring fiat currency because we need to input the recipient's bank account number and their account name, which must match. If they don't match, the funds will eventually be returned to us. Using .bit Alias as an additional verification mechanism when sending assets achieves the same effect. When the application detects that the alias entered by the user does not match the query result, it will not allow the user to proceed with the asset transfer. This is because the user will not continue with the asset transfer if they find that the alias displayed by the application does not match the one they received. Therefore, the user's assets are always secure.
Understanding .bit Alias
You can read our previous article "In-depth understanding of .bit Alias" for more information.
Further discussion on transfer security
1. What impact does it have if .bit Alias Lookup returns an incorrect result?
Although the probability is low, both .bit Lookup and .bit Alias Lookup require wallet/exchange to request data from API service, which may result in returning incorrect results. However, when the former returns incorrect results, it will directly cause users to send assets to the wrong address. When the latter returns incorrect results, it will only cause users to choose not to send assets temporarily, and they will send them after verifying them carefully, without asset loss.
Moreover, if an API service fails to return any result, the former prevents users from continuing asset transfers, while the latter is merely an auxiliary verification tool for enhancing security, and users can still send assets using the address without such verification.
2. Can ENS Primary Record be used as an auxiliary verification method for sending assets?
The principle of ENS Primary Record is similar to that of .bit Alias, but it is not suitable as an auxiliary verification method for sending assets for the following two reasons:
A. Limitations of Primary Record
ENS is built on top of Ethereum, and its smart contracts can only verify the signature of Ethereum private keys. Therefore, except for Ethereum addresses, other public chain addresses cannot use an ENS as an alias. For wallets/exchanges, even if there are no other design issues with ENS, using ENS Primary Record can only improve the security of Ethereum asset transfers. At the same time, in the design of ENS, only one Ethereum address is allowed to use an ENS as its Primary Record. If a user has multiple Ethereum addresses, their needs cannot be met.
On the other hand, .bit Alias is different. Firstly, any public chain address can set a .bit Alias, which comes from the wide compatibility of cryptographic algorithms that .bit has always been proud of (Learn more here). Secondly, a .bit account can store multiple addresses of the same chain, and multiple addresses can use the same .bit account as their alias. We believe that this is more in line with the actual needs of users.
B. ZWJ vulnerability of ENS
For detailed discussions on the ZWJ defect of ENS, please refer to Zero-width characters pose a security risk and existential threat to ENS.
In summary, any user can create their own "vitalik.eth" by inserting invisible characters. In fact, there are already many "vitalik.eth" in the ENS contract. The existence of this defect makes ENS Primary Record completely unusable as an auxiliary verification method to improve transfer security. When a wallet or exchange queries an address's alias through an API service and it returns "vitalik.eth," users cannot distinguish whether it is the real "vitalik.eth" or "vitalik.eth" containing invisible characters. In this case, it may cause even more serious security problems.
Also, it should be noted that:
Other forked ENS projects have also completely forked the limitations and vulnerabilities of ENS. Therefore, they are also not suitable as auxiliary verification methods to improve security.
.bit does not have a ZWJ problem.
Best practices recommendations for all parties involved
Security is of utmost importance. Our recommendations are as follows:
For wallets/exchanges
Users should not be able to send assets directly via .bit/ENS or other DID products.
To enhance security when sending assets, consider using a .bit Alias solution. See our UX guidelines for more information.
For asset recipients
Set up a .bit alias for your address (see guidelines).
Provide both your blockchain address and corresponding .bit Alias to the sender when receiving assets.
For asset senders
Avoid directly transferring assets using .bit/ENS or other similar DID products.
Use wallets/exchanges that prioritize user asset security.
About .bit
.bit is the only cross-chain unified DID protocol that can verify signatures using various asymmetric cryptographic algorithms. This unique ability allows .bit to extend its services to a wider range of users, reaching beyond just the Web3 community.
.bit 's mission is to Empower every community and individual to explore new possibilities through sovereign identity.
Contact us for any inquiry: vivi@d.id
Thanks for the great article. Is there a blog (or how to) for using the .bit alias as a domain? For example, did.id. Also, how to setup subdids like josh.did.id and view the website.