I have a question about ERC20 token contracts in general:
Apparently after verifying on Etherscan, all token contracts become visible to the public.
Isn't that a security risk ?
What if we do not verify our contract ?
Can some of these contracts (that are verified and visible) on the Etherscan be used again for new coins,
or are they copyright protected ?
Thank you in advance!
Apparently after verifying on Etherscan, all token contracts become visible to the public.
Their bytecode is already public when they're deployed. You're just making the source code public too.
Isn't that a security risk ?
Only if your contract contains a security flaw.
But if your contract does contain a security flaw, it's a security risk to deploy it even without publishing the source code. There are ways to "decompile" the bytecode to some pseudocode or even Solidity to some extent, so anyone can see the logic of your contract even if the source code is not published.
What if we do not verify our contract ?
It's a fully functional contract, just without verified source code.
Can some of these contracts (that are verified and visible) on the Etherscan be used again for new coins, or are they copyright protected ?
It depends on the license under which the authors created it. It's possible to bypass the license - so if someone publishes the contract under "Do not copy" license, someone is still able to copy... But that's a legal topic, not programming.
Related
I'm new in the blockchain technology, moreover in some dev tasks related to the blockchain. Nevertheless, suddnely I was asked to implement such a demo back-end Node.js app that:
Task: Get information about all tokens for some wallet address.
For example:
Input:
The wallet address is: 0xB245ac044E3c2e9781C9c848249E2e6b186b080F
Output:
ERC-20 tokens: USDT $100, USDC $200, SHIB $300;
Etherum native token: ETH $500.
I'm not asking about ready-to-use code snippet (but why not?), rather it would be better to know which steps should be proceeded in general using Node.js and Web3.js specifics.
Where I've tried to find the answer:
Stackoverflow: How to get all tokens by wallet address
Stackoverflow: web3.js how to search all the contracts ever created by and address
Stackexchange: How to get all contracts deployed by the address, given the address?
Github: ERC-20-Token-Balance (cool and very simple hello-world project)
Medium: Try out Ethereum using only nodejs and npm!
Each of these helps to understand some moments, but the whole solution is still not obvious for me.
It is very possible that I am missing something for input, also possible that my output is incorrect in some moments. But I hope the general idea of the question is clear more or less.
I'll split your question into several steps, as there is no simple way to fetch the data from the blockchain in the format you want, so you have to "walk a thorny path".
1. Get the list of Token Addresses owned by an Externally-Owned-Account
1.1 Query for Transfer events
A token, or better to say - a contract, which implements the ERC20 interface, emits an event Transfer(address from, address to, uint256 amount) Event every time the token transfer occurs. You can query the blockchain for the past events, where the to is your target account. The event emitters are the contracts, possibly the ERC20 tokens, but also those could be the ERC721 tokens, as they have the same event signature in the interface.
Also notice, an event emitter could be any contract, even not related to tokens, as any contract can emit any event.
Some blockchain nodes could limit the block ranges per request to get the events from, so you have to implement the pagination, as you want to get events from block 0 to latest
1.2 Find out the ERC20 Tokens
You have here several options
a. You can create the list of known tokens from various 3rd party sources (CoinmarketCap, 1inch, Shushiswap, Uniswap) and then filter those Transfer emitters narrowed to those from the known list.
b. Another option, is to fetch ERC20 interface Information directly from the blockchain. Call each Transfer emitter by getting the decimals, name, symbol, balanceOf. If you don't get the exception for the calls, then the contract is highly likely the ERC20 token.
c. Or you can get the contracts ABI (if the contract is validated) from Etherscan, and check if everything from ERC20 interface exists in the ABI.
I have implemented all these steps in the 0xweb cli tool, which uses the dequanto library. You can check the implementation in CTokens.ts#L88
After these steps, you'll get the list of all tokens owned by the account, and their amounts (balanceOf).
2. Get the token prices
Another challenging task, in case you don't use any 3rd party service and stick to onchain data.
a. Query the oracle price feeds like chain.link. But not all tokens are presented there.
b. Get the price directly from DEX, like uniswap, sushiswap, pancakeswap etc. But surprise - no easy way to get the price also here. You can find a stable pair (Some USD stable coin/Your Token), if the pair exists just grab the reserves and the ratio is the price. For less popular tokens there could be only the ETH/YourToken pair, and the price for ETH you can get these steps a) or b).
I've written a more in-depth article: https://dev.kit.eco/ethereum-get-token-price-at-a-specific-block-onchain on how to get the price at any time in the past. And if you don't have the archive node, you just get the price for the latest block.
If you want me to explain some parts in detail, don't hesitate to ask in the comments, I'll update the answer then.
I'm looking at knowing, In order to update a asset,
When should I need to write Transaction in lib/script.js
vs.
when should I be using composer-client code using bizNetworkConnection.getAssetRegistry?
I see that I cant use the feature of event emission in later case, Is there any other reason why I should be using it?
Please help me know.
The important thing about writing a Transaction is that it becomes part of the Agreed Smart Contract. So the creation of one or more assets or participants in the same transaction with the associated logic is agreed. This Transaction is a class and can have a specific ACL rule associated with it (also in the smart contract), whereas if you use composer-client you would add individual assets or participants using a generic system transaction AddAsset or AddParticipant.
So writing your code in a Transaction provides a 'better' Blockchain app with a stronger Smart Contract and improved security.
I've done a fair bit of reading about digital signatures but I can't for the life of me work out why I'd need to verify the signature of a digitally signed file uploaded on a mirror site.
The question popped up when I tried to install Maven:
https://maven.apache.org/download.cgi
The site urges you to "verify the signature of the release bundles against the public KEYS used by the Apache Maven developers".
I understand the need for integrity which a checksum provides (granted MD5 is considered weak) - why do I need to do more? I know the file that I've downloaded has not been modified since the checksum was initially generated.
Digital signatures are supposed to provide integrity, authenticity and non-repudiation.
1) Integrity is already provided anyway by confirming the checksum.
2) Authenticity - verifies identity of signer. In this case, the signer is the owner of the public key (supposedly a maven developer). In this scenario, do I really care who signed the file?
3) Non-repudiation - Do I really care that the developer can't deny the file was signed by him/her? Maybe if the maven developer created a malicious file and I wanted to sue them for distributing it...
I don't see the significance of authenticity here. I KNOW the sender (eg. someMirrorSite.com) is not the one who signed the file since if I use their public key to try verify the signature, it would be invalid. If I use the maven developer's public key all I'm verifying is the fact that the maven developer signed the file (granted they have a valid certificate which links that maven developer with their public key).
So basically the question is: Provided that I trust maven.apache.org, why should I verify the signature of the file hosted by the mirror site when I can just simply verify the checksum of the file?
Is basically a perspective, do I care who made or compiled a file? Who is behind this so called signed document/file/byte array?
Behind a signed file is Private Key Infrastructure, is like having a notarized document when a particular risky transaction is on play and a bunch of lawyers around, why should I care? Well it depends how important that activity is for you or a third party. Let's say You want to sell a company (small business). This is risky, may be not for you but for the third party, he will make sure there is a notary present to witness the transaction and the state he is receiving the company. At this point it becomes clear to you that you also need a notarized document of you selling the company. Who knows what's going to happen next? May be you don't care what happns next, as long as it's sold, so no notarized document (aka digitally signed document).
Check Integrity = Just lawyers
Digitally Signed Document = You don't trust lawyers that much so you need a notary (who is basically a lawyer anyway :-))
If there is a file F, and C = checksum(F), then when you download F you can recompute C and see if it matches the published value. But, how do you know if this published value of C can be trusted? If I am "Evil Inc." I can make a compromised copy of F, call it Fe and then compute its checksum Ce, and publish both on my website. Many people will not bother to even look at the checksum, but even those that do will be fooled, because they will compute Ce too.
Using a Public Key signature as the checksum is an attempt to strengthen this procedure.
SagePay's form callback can be hacked by re-using the success URL that the user is directed to upon a successful transaction. This can create all sorts of problems with duplicate transactions, fake transactions etc.
You can check for a duplicate VPSTxId, but these can be generated anew by hacking around the crypt parameter of the callback URL.
The crypt parameter can also be manipulated to generate a different "Amount" field.
I have not tested what other field values can be changed by hacking the callback URL crypt parameter.
Is there any way (as per PayPal's IPN validation) of doing a double-check callback to SagePay to ensure that the transaction is new and unique?
Thanks for your post. In general we encourage clients to use Server integration where they can. We also constantly monitor transactions for suspicious behaviour and proactively contact our customers if we suspect any malicious activity.
We recommend customers make sure that they’re using the latest version of our integration protocol which is currently v3. Get the latest integration documents.
As Dan suggests you could use the Reporting and Admin API to validate that a transaction does indeed exist on the Sage Pay side but having an additional validation mechanism (like PayPal's IPN) is something we will actively explore.
If you'd like us to update you on this, then please get in contact with our customer services team at support#sagepay.com or 0845 111 44 55.
Sage Pay Support
You should always redirect a user from a success URL.
I personally use a fulfil page (success url), and a thank you page. On the fulfil page, you should obviously only ever process a transaction once (based on the transaction id), and you can store crypt sent with a transaction. The crypt will have to be valid and is only possible to encrypt if you have the encryption key.
So hacking would be extremely difficult unless you are being very security lax, and the hacker would have to know your encryption key to even begin trying to hack it.
Alternatively, you should use the server integration, so that the communications are server-server, not client-server. There is little difference between form and server.
10 immutable laws of security
http://technet.microsoft.com/library/cc722487.aspx
I was wondering if anyone has ever used, built or seen a password recoervy tool that was completely online and didn't require sending some kind of password reset email.
I understand the security concerns and I am completely open to the idea that this is just not a secure way to handle things but I have been tasked by my employer to look into this type of solution. I feel like I have used something like this before.
Our main concern is email spam filters grabbing lost password emails. If there were best practices on formatting these emails that would be a great thing to send over also.
Any thoughts?
THanks
Craig
Almost all security relies on varying combinations of the three things below
Crypto-graphic proof
shared secret
trusted third party
and using them, for a given level of likelihood, to verify that the counter-party in the current transaction, is the same party with whom you had the original contract.
Really thats all "online identity" is - how likely is it that the person talking to me now is the person I was introduced to yesterday.
For example, a password is a shared secret, that both parties know and assume for a given level of likelihood that the other person with the secret is who they think they are.
Thats the easy one.
The security question (Mother's Maiden name) is just a second password in case you forget the first.
OpenID is a trusted third party approach. Stackoverflow trusts google. I try to login to
stackoverflow and SO passes me over to google. All SO sees is google coming back saying "yes he is".
However, compared to email penetration, OpenID is hardly used, so its not going to work as recovery option.
The email password reset is an example of a direct shared secret involving a trusted third party - gmail is "trusted" by both parties, so one can send a shared secret to gmail, and trust that for a given level of likelihood, only the other party will be able to access that shared secret.
Finally cryptography can be used as a trusted third party. If I know your public key I can "trust" RSA and store the new password by encrypting it then putting it on my website. Only you can read it, so it could work as an instant, online password reset. But the penetration of PGP/GPG is so much worse than that of OpenID the idea is a non-starter (*)
What you need is a second channel of communication that you gather at the time of contract - usually it email, it could be openid, a mobile number or their GPG public key.
But you must collect that channel at the time of making initial contract.
Talking of mobiles, I did see a neat one at my local cellphone shop - they texted me a random password, and then the sales assisstant entered in the password when it arrived at my phone - proving the phones owner was in the shop and compliant. (for a given level of likelihood).
(*) actually I think there is a solution - http://www.itmanagerscookbook.com/Attitude/identitycrisis.html. AS you can tell trying to express the concepts above is an ongoing effort.
The only safe alternative I'm aware of is offering a password reset page after a security question (mothers maiden name, but preferably something user configurable/safer).