Protecting the Ethereum community: use proof of address!
How ironic! A few days after publishing a post on medium (now deleted) titled “Protect Yourself: Staying Safe in a Token Sale — How to avoid phishers, scammers, and spammers”, the Enigma project was “hacked”
and about half a million dollars of Ethereum went missing.
I must say that while I applaud the intent — reflecting on safety by giving a few rules for their token sales — I’m afraid Enigma’s advises fall short to being even remotely sufficient.
Let’s see the rules listed by Enigma:
1. Look for official web addresses.
2. Only trust official administrators on Slack and Telegram.
3. Be extremely suspicious of direct messages.
4. Do not trust Slackbot.
All of these rules kind of make sense, but reveal an approach of security which is both naive and too optimistic.
Why? First, because it assumes that all their accounts will forever never get hacked (“trust official administrators on Slack and Telegram”). A real security policy should take into consideration that some accounts or servers may be hacked during the lifetime of the project.
Computer security is hard and even if your audits and security measures are cutting edge, you can never be sure that you are 100% protected. There could be a zero-day hack somewhere waiting for the day of your ICO or you may be failed by a third party providers (your hosting company, your webmail, etc).
So what’s the solution? The Rouge Project came up with its own set of rules which I think go beyond Enigma naive approach and do a better job protecting the community.
Rule 1: stop being complacent and try better
Some rumors attribute the Enigma hack to a leaked password which was used several times with different accounts and without two factors authentication (2FA). I hope it’s not true, since that would count as gross negligence.
Certificates, https, 2FA and strong passwords are necessary good things but state of the art security is a goal which is ever moving and changing : needed security updates on software and servers could be daily!
Our solution is to never believe you have reached the optimum of security and always try to learn and improve (the technical ecosystem but also your own behavior). Here at the Rouge Project, we have a weekly meeting on security during which we audit and try to improve ourselves in this field.
For example, we concluded that the use of Slack in many Ethereum projects may be counter-productive. Slack is a fantastic tool which I love but was built for teams, meaning people with a certain degree of trust between them. I’m not sure it’s the right medium when you grow a community which members don’t know each other.
Rule 2: Assume real life scenarios; hackers may succeed
I know it’s hard to admit but maybe you will get hacked even if you do follow rule number 1!
So projects need to think solutions which are bullet proof against some degrees of successful hacking of their project (the maximum the better).
For example, the number one problem in Ethereum token sales is when people send ether to the wrong address! Hackers may replace your correct address by their own on your website if it is compromised (observe here Enigma rule 1 fail!). Or hackers may send emails or newsletters that look legit with the wrong address, etc.
At the Rouge Project we will propose in our future token sales a very simple concept which could resist quite a lot of hacking : the proof of address.
The contract address of our token sales will have to be authenticated by myself (
) or our Lead Developer () to be valid.The authentication system is straightforward: we will both sign a message validating the contract address using Ethereum signature mechanism (this procedure is a standard functionality of Ethereum : see for example how this message is signed). Thus anyone can go independently verify them (e.g. on etherscan.io).
The two Ethereum accounts used to sign have offline private keys and have long ago been publicized widely — not only on self-hosted pages! — in many different places (bitcointalk, etc). Preferably, it’s better to choose places where past posts are immutable (github, twitter), or have cached version in Google.
If all projects would do the same and people had learned the reflex to authenticate an address this way before sending ether, phishing attempts would become much harder!
