Recent incidents of users’ assets being stolen due to the use of off-chain signatures have raised concerns about the underlying principles and prevention methods. What is the principle behind these incidents? How can users protect themselves? And why is it related to Uniswap and on-chain data? This article will provide a clear explanation of the operation mode behind the Permit function and the knowledge users need to protect themselves.
Table of Contents
Toggle
Off-chain Signatures
What are Off-chain Signatures?
Advantages of Off-chain Signatures: Better User Experience
Disadvantages of Off-chain Signatures: Easily Ignored Security Risks
Permit Function
Problem-solving: Poor On-chain Authorization Experience
Improving User Experience with the Permit Function
Permit Function Not Suitable for Early Tokens
Permit2 Contract
Uniswap Introduces Permit2 Contract
Principle of Permit2
Principle of Off-chain Signature Theft
Increased Risk of Off-chain Signature Permit Function
Difficult to Trace Off-chain Signatures
How Users Can Protect Themselves
A Series of Design Flaws
To understand how the Permit function can be used to steal user assets, it is necessary to understand the principle behind off-chain signatures.
Off-chain signing is a common user interaction method in the blockchain industry. It is commonly used for wallet connections, website login, and ensuring that users have read disclaimers, among other things. It is a unique interaction method using Web3 wallets that brings user power into the virtual world.
Using the login process of OpenSea as an example, it uses the off-chain signing method to not only ensure that the user is the wallet holder but also to confirm that the user agrees to the terms of service and privacy policy.
Off-chain signatures have many advantages, the most obvious being the reduction of gas fees and faster completion. Overall, off-chain signatures provide a better user experience compared to on-chain transactions.
The biggest problem with off-chain signatures is that they may expose users to the risk of asset theft. Although off-chain signatures do not upload data to the blockchain, some on-chain contract functions can use the user’s signature information as parameters. This means that anyone (or a smart contract) with access to specific signature content can invoke on-chain functions (such as the Permit function) and affect the user’s assets.
Different signatures have different risks, especially when the content of some signatures is not understood. It is recommended to be cautious and not sign without understanding the content to ensure security.
A commonly used on-chain function that can use user signatures as parameters is the Permit function. It provides similar functionality to approvals but allows users to authorize without paying gas fees through off-chain signatures.
Users who have used on-chain services are familiar with the confirmation screen shown when using tokens for on-chain contract operations. The approvals function is used for on-chain authorizations, allowing contracts to access tokens in wallets for services.
However, due to the variety of tokens and the need for reauthorization for different contracts, users are frequently required to perform token approvals, which not only takes time but also incurs gas fees. This severely impacts the user experience.
To address this issue, EIP-2612 was introduced as an extension to the ERC-20 token standard, proposing the Permit function. This function allows token authorizations to be completed by using off-chain signatures as parameters, eliminating the need for users to pay gas fees for authorizations.
The Permit function requires the following signature content:
– Authorizer’s address
– Authorized address
– Token contract address
– Authorization time
– Authorization amount
In an ideal scenario, similar to signing a contract in real life, users can adjust the parameters according to their needs before signing to ensure their rights. Compared to approvals, the Permit function provides more flexibility.
However, since many tokens have already been launched and their contracts are immutable, the Permit function is only applicable to newer tokens, limiting its usage scenarios.
To solve this problem, the Uniswap team developed a new smart contract called Permit2. When launching the Universal Router feature, Uniswap integrated the Permit2 contract and made it available on various networks, including Ethereum, Optimism, Arbitrum, Polygon, and Celo, allowing all tokens to have the Permit function.
If older token contracts do not have the Permit function, the approvals function can still be used. The Permit2 contract is inserted between the Dapp contract and the token contract. The Permit2 contract receives off-chain signature data from the Dapp, verifies it, and interacts with the token contract on behalf of the Dapp. Each token only needs to go through the approvals function once, saving the number of token authorizations for different Dapps or users.
Uniswap’s influence has encouraged other Dapps to integrate Permit2, which will make almost all tokens and services only require the Permit2 contract for authorization.
Based on the background knowledge above, it is now possible to understand why users who have used Uniswap are at greater risk of signature theft.
Since off-chain signatures do not require gas fees, they are often overlooked in terms of security. If a malicious website tricks users into signing content that meets the requirements of the Permit function, the user’s tokens can be stolen by third parties.
The above example is a signature that meets the format of the Permit function. Most smart contracts default the authorized token amount to an infinite number (10^31 tokens), and the authorization time is calculated to be 54 years, resulting in a long-term unlimited authorization. If this content comes from a malicious third party, the user’s assets will be at great risk.
It should be noted that the use of off-chain signatures is only possible if tokens have the Permit function. However, with the introduction of the Permit2 contract, the situation has changed. As more protocols integrate the Permit2 contract, tokens used by users of Uniswap or other integrations face the same risks. (This is also why phishing incidents involving the Uniswap contract occur.)
Off-chain signatures do not have a record on the chain and are mostly stored in private or project databases for easy retrieval. Therefore, compared to on-chain data or on-chain authorizations, they are not easily traceable or revocable, making permit authorizations more vulnerable to security risks.
As a user, if you are not familiar with the content of off-chain signatures, there are several ways to reduce the risks associated with token designs:
– First, do not sign unfamiliar content without understanding it.
– When encountering approval confirmation screens, adjust the authorization amount to match the transaction requirements (although this may require multiple authorizations for repeated transactions).
– Although off-chain signatures are difficult to trace, tools like revoke.cash can be used for queries.
– Use wallets that store small amounts of assets for off-chain signatures.
Whether it is the Permit function or the Permit2 contract, the goal is to improve the user experience. However, ultimately, it has put more general users at risk and added more cumbersome processes (creating multiple wallets, multiple approvals) to ensure asset security, resulting in a worse overall user experience.
However, many people have recognized this problem and have proposed potential solutions. It is believed that the industry will become more mature in the future, but it will take time for development. As early participants in the industry, it is our responsibility to pay attention to the security of our assets.
Please make sure to inform your friends about the security risks associated with off-chain signatures, as the current on-chain environment is constantly changing.