If you want to use ERC20 tokens on DeFi protocols such as Uniswap, Aave, and Year, you need to authorize the dApp to use these tokens. This is the so-called ERC20 authorization.
Original Title: Introduction | Unlimited Token Authorization-What can we do?
Written by: Rosco Kalis
Translation & Proofreading: Min Min & A Jian
The hottest area on Ethereum these days is DeFi. The main DeFi applications include lending, pledge and trading of ERC20 tokens. If you want to use ERC20 tokens on DeFi protocols such as Uniswap, Aave, and Year, you need to authorize the dApp to use these tokens. This is the so-called ERC20 authorization . These authorizations are essential for the operation of the DeFi platform, but if they are not controlled, it will be very dangerous.
With the native token ETH on Ethereum, you can send ETH to the smart contract and call the smart contract function at the same time. This is achieved by the so-called payable funtion. However, since the ERC20 token itself is a smart contract, you cannot call its functions by directly sending the token to the smart contract.
Therefore, the ERC20 standard allows smart contracts to use the transferFrom() function to transfer tokens on behalf of users. For this, users need to allow smart contracts to transfer tokens on their behalf.
In this way, the user can “deposit” the token into the smart contract, and the smart contract will update its status to show the deposit. Conversely, if you send ERC20 tokens to the smart contract, the contract will not update its state (for example, credit the deposit to your account).
For example, if you “deposit” DAI into Aave to earn interest, you must first allow the Aave contract to withdraw some DAI from your wallet. Then you call the function in the Aave contract to specify the amount of DAI you want to deposit. Then, the Aave contract uses the transferFrom() function to withdraw the corresponding amount of DAI from your wallet, and credit the same amount of aDAI tokens to your account.
When depositing a specific amount of ERC20 tokens (such as 100 DAI) into the contract, you can choose to set the authorization amount to this amount. However, many applications will ask users for unlimited authorization.
This leads to an excellent user experience because users do not need to re-authorize each time they deposit. After setting up unlimited authorization, the user only needs to agree once, and then this process will not be repeated when depositing.
However, this setting has great drawbacks. As we all know, even mature projects may have loopholes. Once you give these platforms unlimited authorization, not only your deposit will be put at risk, but also the tokens in your wallet.
On Devcon 5, I discussed this issue with Paul Berg for the first time. At this conference, Paul made a statement on the issues discussed in this article. When developing Sablier, Paul discovered a loophole in his smart contract (it has been fixed!). Not only is all DAI ($100) deposited into the smart contract at risk, but the DAI (10,000) in the wallet of all testers US dollars) too!
For a long time, the risk of unlimited authorization is mainly theoretical. This vulnerability was fixed before the Sablier platform developed by Paul was officially launched. At that time, there was no attack using ERC20 authorization, but as long as the platform continues to request unlimited authorization, problems will occur sooner or later.
Last year, we have seen several attacks using ERC20 authorization.
Unexpected vulnerability
Earlier this year, Bancor had a vulnerability that compromised user funds. The function that executes the ERC20 transferFrom() function becomes a public property (no longer a private contract private property), so anyone can execute the function and take away the funds in the user’s wallet. Bancor executed a white hat hack, controlled the loss, and returned the funds to the user.
Malicious exploitation of vulnerabilities
In addition to Bancor’s unexpected vulnerabilities, there are also many cases of malicious exploitation of vulnerabilities. In the DeFi boom this summer, people are caring about various DeFi fork products named after food, including some scams. Even if people only deposit a small amount of tokens to avoid risks, the tokens in their wallets will be at risk due to unlimited authorization.
ZenGo discovered an exploitable vulnerability in a project called UniCats. People can deposit Uniswap (UNI) tokens, and then obtain MEOW tokens through liquidity mining (MEOW tokens cannot be forged). But if you want to deposit, the user must provide _unlimited authorization_. If the project is attacked, the attacker can not only take the deposit of the project, but also all the UNI tokens in the user’s wallet .
Another example is the Degen Money project. The Degen Money project uses a not very clever (but quite “effective”) approach. This project did not develop its own smart contract, but instead created a front-end to perform two authorized transactions. Once to a running smart contract, another time to a completely different address.
Since many people did not specifically check the wallet address, the attacker could take away the tokens in the user’s wallet.
In general, hardware wallets are much safer than mobile phones, laptops, and browser-based wallets. The reason is that the private key that controls the funds is stored securely in the hardware wallet and never leaves the device. Therefore, through a hardware wallet, you can ensure that no one can steal your private key.
The problem with ERC20 authorization is that no one needs to steal your private key to get the tokens from your wallet. Therefore, hardware wallets cannot prevent the malicious exploitation of vulnerabilities discussed in this article.
Using hardware wallets is still a good habit, because hardware wallets can indeed protect you from other vulnerabilities. However, you need to be aware that hardware wallets cannot resist authorization vulnerabilities and many other smart contract vulnerabilities.
In Devcon’s speech, Paul mentioned some solutions to the problem of unlimited authorization. Each of these programs has advantages and disadvantages. One of the most practical solutions is the batch-to-use model. In this mode, the application will only ask the user to authorize the exact amount, rather than unlimited.
The user experience of this scheme is indeed worse, because every time a user wants to send a transaction, a new authorization transaction needs to be sent, and it can no longer be done once and for all like unlimited authorization. The disadvantage of this model is that it will increase the cost of transaction fees. If transaction fees soar as last year, it will cause a lot of trouble.
Another alternative is to let users choose to authorize only the amount that needs to be spent at the moment, or authorize a higher amount for subsequent transactions. Several projects have adopted this strategy, such as 1inch.exchange and Curve.fi.
Another solution to reduce transaction costs is to use standards such as EIP2612, allowing users to set their authorization quota (for free) by signing a message, instead of sending a transaction. However, such standards have not been widely adopted, and there are not many tools built around them.
Since ERC20 authorization is an indispensable part of many smart contracts, it is not feasible to completely stop authorization. But when possible, try to avoid unlimited authorization.
People have understood this problem better than a year ago, so some dApps allow users to choose to authorize only the amount currently required to spend, but most dApps still cannot. Nevertheless, high-end users can also reduce their authorization limit through the Metamask interface.
When using a dApp, please think about whether you need to use this dApp frequently, and whether you trust this project (if so, choose unlimited authorization), or whether you will only use this dApp occasionally, or do not trust this project at all (if it is , Select small authorization). In either case, you’d better check your authorization limit regularly (e.g. monthly) and cancel authorization for dApps that you no longer use.
In order to check and revoke these authorizations, I developed a tool called revoke.cash. With this tool, you can check the token balance and authorization limit of the address, and then you can easily revoke or reduce the authorization. Similar tools include approved.zone and so on.
Many decentralized applications cannot operate without authorization, but unlimited authorization is usually not good for security. There have been several incidents of exploiting ERC20 authorized vulnerabilities in 2020, and people’s understanding of this issue is much deeper than a year ago. As a user, you can take some measures to reduce the risks described above, including regularly checking and revoking redundant authorizations.
Original link:
