An essential part of building any application on Sui is preventing exploits and attacks by threat actors. A focus on security is critical to reducing risk of asset loss for users and reputational harm for developers and businesses.
Members of the Sui security and cryptography community have compiled some best practices that application developers should be mindful of and avoid during their development process. While some lessons are unique to Sui, many others apply equally to all blockchain applications.
Use different addresses on Devnet, Testnet, and Mainnet.
Assets stored on Devnet and Testnet do not have monetary value and these networks may be reset from time to time. Assets on Mainnet, however, have real monetary value and inadvertent access by inappropriate actors may result in financial exploits. It is advisable to use separate credentials between Devnet/Testnet and Mainnet, so that Mainnet access is limited to those with legitimate and essential business reasons. Reusing addresses between networks could result in unnecessarily broad access and increase the likelihood of operational errors.
Hardcoded keys and mnemonics shouldn’t be stored in public GitHub repos.
Account keys and mnemonics are important wallet credentials that control access to on-chain assets. While it may be tempting to store these credentials in a GitHub repository along with the rest of the application code, if the repository is public it allows open access to key materials. GitHub is also a revision-controlled repository. Once keys or mnemonics have been added, even if the information is removed others can still access the credentials by browsing the repository’s history. This is especially harmful if key materials are hardcoded rather than generated by code.
Assert conditions in both on- and off-chain UI code.
In general, it is possible to access public on-chain smart contract functions directly from outside of the UI via CLI tools or bots. If there are important conditions for your application, such as minimum or maximum transfer amounts, it is important to assert checks for these conditions in both the frontend code and the smart contract code, otherwise essential checks can be bypassed, resulting in exploits.
Object IDs are not appropriate sources of randomness or entropy.
Sui object IDs are assigned by a quorum of validators at the time of object creation. Once created, the object ID serves as a globally unique identifier that remains over the lifetime of the object. This persistence makes object IDs a poor source of randomness and entropy. Erroneously relying on object IDs for applications that depend on pseudo-randomness or randomness (lottery, simulation, cryptography) for proper functioning can lead to straightforward exploits. In fact, if any fields consistently present identical bytes during repeated calls to the dryRun RPC, such fields would be an unsuitable source of randomness. Clock() is also not a good source of randomness as it can be subject to manipulation.
Be sure to restrict access to an application’s VRF (Verifiable Randomness Function) or Signature.
VRFs are frequently deployed to ensure randomized outcomes (eg, a lottery function that selects winners with varying probabilities or a signing function that generates a cryptographic signature with varying probabilities of being guessed). However, if a VRF is directly accessible by others and not locked down within an application, it becomes feasible for threat actors to invoke the VRF outside of the nominal application code paths. In the case of a lottery, a threat actor could invoke the VRF ahead of time to predict the outcome of the lottery for financial gain. In the case of a cryptographic signature, being able to gain the ability to sign arbitrary inputs is equivalent security wise to having the signing key itself be compromised.
Take Action Now
Implementing this short list of tips will make on-chain applications more robust, more secure, and most of all more trustworthy to end users. If you have further questions and would like help on how best to secure your Sui applications, sign up for engineering office hours for an in-depth technical consultation.
