feat(docs): add security best practices #1070
Conversation
|
Closed all comments from tact-lang/tact-docs#397 |
|
Docs CI is failing |
|
|
||
| ## Insecure random numbers | ||
|
|
||
| Note that [`random()`](/ref/core-random#random) function is pseudo-random and depends on [logical time](https://docs.ton.org/develop/smart-contracts/guidelines/message-delivery-guarantees#what-is-a-logical-time). A hacker can predict random by brute-forcing the logical time in the current block. |
There was a problem hiding this comment.
Not really. If a hacker does not own a Validator Node (or does not agreed with validator ) he can do nothing if you yse randomize_lt() before generating a random. And I guess this link should be provided (https://docs.ton.org/v3/guidelines/smart-contracts/security/random-number-generation). It is still not 100% correct but surely better than nothing
There was a problem hiding this comment.
But no one should use random in external_message receivers. Random there can be hacked even if person is not a Validator and even if you use randomize_lt()
There was a problem hiding this comment.
However, a commit-and-disclose scheme is sometimes possible. First, both sides generate offchain a number each, and send a hash of their numbers to the contract. After both hashes have arrived, the original numbers can be sent - and their sum can be used, for example, as a randomizer.
|
|
||
| ##### Do's ✅ | ||
|
|
||
| Always include and validate a unique identifier, like seqno, to differentiate messages. Update the identifier after successful processing to prevent duplicates. |
There was a problem hiding this comment.
Or, you can implement replay protection like it is done in Highload V3. It is not seqno-based
Issue
Closes #1069.
Closes tact-lang/tact-docs#72.
Checklist