Table of Contents
To get a local copy up and running follow these simple example steps.
To get a local copy up and running follow these simple example steps.
-
npm
npm install npm@latest -g
-
hardhat
npm install --save-dev hardhat
npm install @nomiclabs/hardhat-ethers @nomiclabs/hardhat-waffle
run:
npx hardhat
- Clone the repo
git clone https://github.com/Aboudoc/Signature-Replay-Attack-demo.git.git
- Install NPM packages
npm install
If you need testnet funds, use the Alchemy testnet faucet.
This project shows the Signature Replay Attack and how to to be safe with signature verification
To learn how to verify a signature, check this repo: Verify-signature-demo
There are 2 ETH in SignatureReplay contract.
Owner of SignatureReplay will sign a signature to approve your contract to withdraw 1 ETH.
There are 2 ETH in SignatureReplay contract. Drain all ETH from it.
Sometimes in smart contracts it is necessary to perform signature verification to improve usability and gas cost. However, consideration needs to be taken when implementing signature verification. To protect against Signature Replay Attacks, the contract should only be allowing new hashes to be processed. This prevents malicious users from replaying another users signature multiple times.
To be extra safe with signature verification, follow these recommendations:
- Store every message hash processed by the contract, then check messages hashes against the existing ones before executing the function.
- Include the address of the contract in the hash to ensure that the message is only used in a single contract.
- Never generate the message hash including the signature.
To go further, learn more about Replay Attack Vulnerability in Ethereum Smart Contracts Introduced by transferProxy()
Often, people assume that the use of a cryptographic signature system in smart contracts verifies that signatures are unique, however, this isn't the case. Signatures in Ethereum can be altered without the private key and remain valid. For example, elliptic key cryptography consists of three variables: v, r, and s and if these values are modified in just the right way, you can obtain a valid signature with an invalid private key.
To avoid the problem of signature malleability, never use a signature in a signed message hash to check if previously signed messages have been processed by the contract because malicious users can find your signature and recreate it.
- https://medium.com/cryptronics/signature-replay-vulnerabilities-in-smart-contracts-3b6f7596df57
- https://medium.com/cypher-core/replay-attack-vulnerability-in-ethereum-smart-contracts-introduced-by-transferproxy-124bf3694e25
- https://swcregistry.io/docs/SWC-117
- https://eklitzke.org/bitcoin-transaction-malleability
- https://hackernoon.com/what-is-the-math-behind-elliptic-curve-cryptography-f61b25253da3
- deploy on goerli and test by signing off chain using metamask
See the open issues for a full list of proposed features (and known issues).
Contributions are what make the open source community such an amazing place to learn, inspire, and create. Any contributions you make are greatly appreciated.
If you have a suggestion that would make this better, please fork the repo and create a pull request. You can also simply open an issue with the tag "enhancement". Don't forget to give the project a star! Thanks again!
- Fork the Project
- Create your Feature Branch (
git checkout -b feature/AmazingFeature) - Commit your Changes (
git commit -m 'Add some AmazingFeature') - Push to the Branch (
git push origin feature/AmazingFeature) - Open a Pull Request
Distributed under the MIT License. See LICENSE.txt for more information.
Reda Aboutika - @twitter - reda.aboutika@gmail.com
Project Link: https://github.com/Aboudoc/Signature-Replay-Attack-demo.git