New answers tagged security
1
Take a look at the documentation on Security about all known bugs. It is a list of bugs from 0.3.0 and up to today formatted in JSON with the information on when the bug was introduced, whether it has been fixed, when it has been fixed, what version of Solidity it impacts.
0
Ok, so what i was planning on doing was to use Open Zeppelin Payment Splitter to be the receiver of the Royalties when sold through a Market Place.
Are you saying this will not work since the receiver would be a contract?
2
I was in the same situation - my credentials were stolen when i connected metamask to scam website that looked like legit one. ETH scavenger was eating all my ETH in wallet and my NFTs were stuck in there.
Fortunately i was able to rescue them using Flashbot relay to frontrun bot writing my own script. Basically using flashbots you can create multiple ...
0
Check out a ReentrancyGuard contract on OpenZeppelin. Using the modifier nonReentrant() will ensure that if the receiver is a contract, it will not be able to call the same function again until after it is finished. You will not need to apply the withdrawal pattern here (though it is never bad to be too cautious)
0
A user will be able to fake their public address for read only purposes (see impersonator) but will never be able to fake a signature for a message or transaction.
I'm not actually sure what your use-case is, but you can safely bind an address to a certain user through a simple utility involving asymmetric encryption. If you have a frontend + backend ...
0
I am running MetaMask 10.8.1 and I felt this issue in remix. I checked that my address is okay by running it on etherscan. then I compiled the solidity contract file in remix and that enabled "AtAddress" button. You need to compile the contract first.
0
I developed my contract using ECDSA
I have no idea what you are trying to say by that and I am certain that you are just expressing yourself wrong here ;)
You wrote a contract using solidity, right?
Let's get back to the original question: Security of private key.
As you already stated, you can't keep your private key in the frontend. Anyone would be able ...
1
ERC-20
Let's assume that you are only making transactions from your EOA to the malicious contract, and never to any other contract. This is an important assumption since many phishing websites will pretend that you are not interacting with those ERC-20 when in fact you are making an unlimited approval.
In that case, the malicious contract cannot access any ...
0
It is about 9 months since this question was asked, but for new sweeper bots victims, I created this repo https://github.com/eniolasonowo/CompromisedWalletTokenRescue, to help victims rescue their funds/assets (Tokens, Stakes, NFTs) from compromised wallets.
0
Also, Unstoppable Wallet on iOS/Android supports this.
0
There are many types of scam on the web, but social engineering tops the list of the most effective ones. Posing as a representative of a project/company you trust to gain something from you is a scam as old as time. DApps do not require your 12 word phrase (generally, only wallet providers need that key). You should never share that key with any entity you ...
0
There's an even simpler implementation called Burner Wallets for Ethereum that doesn't even store a password hash: see https://burnerwallet.co/ -- it seems so far that there haven't been any attacks. I wouldn't use just password hashes, as then you are vulnerable to a rainbow attack if localstorage is compromised (and that seems like the whole point of your ...
0
The solidity contract type (in your case TokenType) does not perform any runtime checks and is primarily for compile time type enforcements.
As @Ismael mentioned the best solution right now is EIP-165. This EIP allows contracts to return of they support specific interfaces.
A very explicit way is to check the code hash of a contract and only allow contracts ...
Top 50 recent answers are included