gfermah A payment system can have strong rules and still fail when too much authority sits in the wrong hands. In March 2022, the Ronin Network suffered a major security breach that exposed the danger of poorly managed signing authority. Attackers compromised five of the network's nine validator private keys and used them to authorize fraudulent withdrawals from the Ronin Bridge. The stolen assets amounted to 173,600 ETH and 25.5 million USDC. The interesting part is that the attackers did not need to break the bridge's smart contract. They obtained enough valid signatures to pass its existing authorization requirements. Four compromised validators belonged to Sky Mavis. The fifth was associated with Axie DAO, which had previously allowed Sky Mavis to sign on its behalf during a period of high transaction demand. That permission was not revoked after the arrangement ended. The incident showed that distributing authority is not enough. The permissions behind that authority must also be carefully managed. Fermah Pay approaches operator security through multiple layers. Its Stellar implementation includes configurable key management for third-party operators. The documented design provides separate roles, a 2-of-3 administrative arrangement, a cold reserve and support for AWS KMS, hardware security modules and other key stores through a remote-signer interface. Each component addresses a different part of the operational security problem. Separate roles help divide responsibilities instead of giving every operator unrestricted access. The cold reserve provides a separate layer for funds that should not be exposed to routine operations. External key-management systems give operators options for protecting signing credentials outside the application itself. The 2-of-3 administrative arrangement is another important safeguard. It means an administrative action requiring that threshold cannot be approved by just one of the three designated keys. Two approvals are required. This is not the same mechanism Ronin used. Ronin required five of nine validator signatures to authorize bridge withdrawals. Fermah Pay's 2-of-3 arrangement concerns administrative control over its system, not the validation of individual payments. However, both designs highlight why authority should not depend on one credential or one person's unrestricted control. There is another lesson in the Ronin incident: permissions must have an end date. The Axie DAO signing arrangement had originally been introduced to help handle increased transaction activity. But when the arrangement was no longer needed, the authorization remained active. That overlooked permission later became part of the attack path. For infrastructure handling customer funds, access management cannot stop at granting permissions. Operators also need to review existing access, remove unnecessary authority and keep administrative responsibilities clearly separated. Fermah Pay's documented approach makes key management and administrative approval explicit parts of its infrastructure. This matters as billing systems increasingly serve APIs, AI agents and other automated services. When payments happen in the background, users depend on more than the payment contract. They also depend on the people, software and credentials operating the system. The Ronin incident reminds us that a valid signature does not automatically mean a legitimate decision was made. Security must protect not only how money moves, but also who has the authority to make it move. @fermah_xyz @7wealthh
yang🦾🟣Share

Source:Show original
Disclaimer: The information on this page may have been obtained from third parties and does not necessarily reflect the views or opinions of KuCoin. This content is provided for general informational purposes only, without any representation or warranty of any kind, nor shall it be construed as financial or investment advice. KuCoin shall not be liable for any errors or omissions, or for any outcomes resulting from the use of this information.
Investments in digital assets can be risky. Please carefully evaluate the risks of a product and your risk tolerance based on your own financial circumstances. For more information, please refer to our Terms of Use and Risk Disclosure.

