Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
name: Bug Fix Contribution
description: Use this template when contributing a bug fix.
labels: [bug, pull request]
Fix nonce implementation to guard against replay attacks
Nonce is shorthand for Number only used once. We use this to protect
against replay attacks. Since receivers in the bittensor network are
decentralized, requiring domain names for every receiver would be
self-defeating. This forces us to depend on HTTP communication which is prone to
many more attacks than HTTPS. One of these problems is called a replay attack.
This is when a malicious agent intercepts a message being sent to a miner and
sends it again, "replaying" the request.
A nonce is only used once, so sending another request with the same nonce is
required to fail. To accomplish this the server holds a dictionary of sender
identifiers -> last nonce, and makes sure the next nonce is less than the
previous.
This problem here is that nonce's are held in memory. If the server restarts
then there is no nonce held in memory and therefore a duplicate request can be
freely sent by a malicious user.
To solve this, receivers should both keep the last nonce in memory
and require nonces to be UNIX timestamps with a pre-determined delta to the
current time. A delta of 4 seconds was chosen since miners generally take a few
seconds to restart & requests should be able to reach an axon sent from a dendrite
and start the verification process of the request within 4 seconds including network
latency. This way if an attacker attempts to replay a message after the
receiver re-starts the replayed nonce time stamp will be too far behind the
delta to the current time and be rendered invalid.
Example Flow
Testing
There are 5 routes that need tested before this PR is merged.