Enhancing Permission Security in Tron

[zonanaza]

Context: The increasing number of phishing attacks through cloned websites offering fake airdrops or rewards is compromising the security of Tron accounts. Users unknowingly delegate full control of their accounts to malicious actors by signing transactions, losing control despite still holding the private keys.

Problem: Currently, when the Owner permission is delegated to another account, the original private key holder cannot recover control. This issue not only impacts individual users targeted by scams but also affects businesses using multisignature systems. If an employee with critical permissions leaves the company, the original account owner cannot revoke those permissions, leaving the account vulnerable.

Practical Examples:

Phishing Attacks: A user signs a transaction to claim an airdrop but unknowingly delegates the Owner permission to a fraudulent account, losing access to their account.
Business Management: In a multisignature setup, if an employee leaves and has delegated permissions, the account remains exposed if those permissions cannot be revoked.
Proposed Improvement: Introduce a feature allowing the private key holder to reverse any permission updates, including the Owner permission. This would ensure that the legitimate account owner retains ultimate control over the account.

Justification:

User Security: Protect users from phishing scams and frauds that could result in the loss of control over their accounts.
Business Flexibility: Enable businesses to manage multisignature systems more efficiently, maintaining control over permissions even in case of personnel changes.
Increased Trust in Tron: Strengthening control over permissions will enhance the platform’s security and boost user confidence, making Tron more resilient against attacks.
Conclusion: The private key holder must have the ultimate authority to revoke any permission, ensuring they always retain full control of the account. This improvement would protect users from phishing attacks and enhance overall security for assets managed in Tron, offering more effective and secure account management.

[tomatoishealthy]

Very valuable point, but I have some different views on the scope of private key permissions:

Problem 1: From the perspective of general multi-signature usage scenarios, if an address is a multi-signature account, it will not be allowed for an administrator address to skip multi-signatures and directly manipulate the address. I personally think that the first problem is not in line with the spirit of decentralization and blockchain.

Considering that users may indeed lose their permissions without knowing it, an optimization solution that can be considered is to emphasize transactions involving permission changes through the wallet UI so that users understand the risks of each operation.

Problem 2: I understand that it is also a general multi-signature usage scenario, and even multi-signature addresses on other chains will also face the problem of permission delegation.

The workflow of TRON's multi-signature can be simply understood as TRON abstracting a permission layer for the address, that is, the user set in the permission has the address permission, each user has a permission weight, and the permission defines the minimum weight threshold for manipulating the address. In other words: ignore the inactive user, as long as the weight of the remaining other users exceeds the specified threshold, they can delete the inactive user, so as long as the address permissions are properly allocated, there will be no problem. This problem is mainly a weight management issue, not a problem with TRON itself.