Let’s talk about Security on Ethereum

Ethereum has got to be one of the most exciting projects since we started linking computers together.

Its gigantic ups and downs create waves of controversy but the good news is we’re learning from them, the bad news is people are willing to risk a lot of money; which makes for REALLY bad headlines.

Having said that I’d like to take a moment to discuss three kinds of recent attacks that have cost people millions in fiat currency, what they are, how they work, and what we can do as a community to reduce the risk.

The wrong web 2.0 address

Wow, how many reddit posts are there about MyEtherWallet?? u/Insomniasexx at MyEtherWallet tends to get agitated about it and for good reason. How many times does she have to say

DON’T USE LINKS!

Just about every other day I peruse the thread she’s had to say it again. Like

• Here https://www.reddit.com/r/ethereum/comments/6o04b2/protips_how_not_to_get_scammed_during_a_token_sale/
• Here https://www.reddit.com/r/ethereum/comments/6mevz3/this_is_your_friendly_weekly_reminder_that_this/
• And Here https://www.reddit.com/r/ethereum/comments/6lfy73/warning_stop_clicking_links_stop_sending_to/

What it is: Bad actors creating identical web pages at web addresses that are virtually identical to the real address.

How it works: myeteherwallet.com, myethirwallet.com, myetherwallet.com.me

You see that? It’s confusing and you’re LOOKING FOR IT because I just told you. Now imagine that being in an address bar after clicking a link that says MyEtherWallet.com.

I know I’m using this one example of MEW but this is an everyday issue it seems! Once you’re there the website will tend to use a lot of technical verbiage to get folks ‘just wanting to transfer ether’ to slip a private key in somewhere and voila, your account is emptied fairly quick.

What to do: Right now I see a lot of encouraging awareness and unfortunately it’s not going to be enough. For as long as anyone has to use a web address this is going to be a vulnerability.

We need to keep moving away from web 2.0 and press hard for downloaded, installed front-end applications with hardcoded points of entry. We cannot expect users to be this vigilant all of the time and especially to go mainstream.

I encourage any development team that plans on providing consumers with the ability to transfer value to put application packaging tools at the top of your list and distribute the code.

What about now: TYPE THE ADDRESS MANUALLY! KNOW WHAT PAGE YOU’RE ON AT ALL TIMES, ESPECIALLY WHEN MOVING CURRENCY! NEVER, EVER, EVER, EVER, EVER, EVER, EVER DISTRIBUTE YOUR PRIVATE KEY TO ANYONE ANYWHERE!

No real service needs your private key, they need a transaction SIGNED by your private key.

YOU sign your own transactions and if you get stuck, need to transfer, and run into something that says ‘paste your key here’ you can’t close that application fast enough but you need to do it as fast as you possibly can comprehend.

Webpage or other info spoofing

This one recently took ICO investors by surprise.

What it is: Bad actors replacing legitimate donation or auction addresses with bad addresses.

How it works: 0x23F47686C26Aaf2Cc3227B1Cf7e19b6C8760eD4b vs 0x23A47616C26Aa2Cc3227BrCf7e19b6Ct620eD4b

This is even worse than the web address thing. Yet, the market is OK with sending money, again millions in fiat currency, to a random 20-byte address. Obviously once you send your ether or other cryptocoin to a specific address it’s gone.

What to do: First off, here’s the thing.

This is a risk that people have willingly accepted!

So we actually don’t HAVE to do anything until they demand a better standard. Having said that, when the market no longer wants to throw their money at random bytes, we will need a solution.

If we want to be proactive now we should make heavy use of the Ethereum Name Service.

It’s ready and available and if you have an ICO or donation address, you need to give it a name and develop the methods for consumers to reach you using that name, period.

The name you want is not available or is less than 7 characters? TOO BAD! Just GET A NAME and distribute that to the public. It’s way better than trying to get them to jot down the correct 20-byte address to your token contract.

But then someone will get a similar name and spoof again!

We can’t eliminate all risks but this is more digestible than trying to communicate what is essentially byte-code.

What about now: Well, as in the case of CoinDesk, if your page gets hacked, the wrong address is published, and ICO spenders are willing to send ether to a hexadecimal number not copied beforehand, there’s not much that can be forced until the money dries up. P

People will have to demand a better way. Having said that, the ENS IS available now and I see no reason that a team raising into the 8 figures should not have a tool to use it for their raise.

Last but certainly not least… Bad contract code!

Obviously this is one hits a sensitive spot right now.

What it is: Faulty code gives bad actors access to a contract that, in turn, has access to value and they steal it.

How it works: Anybody technical enough already knows, but as far as the non-technical, in the case of this last week, the door to the record that states who owns the house was left open and they changed the owner’s name

What to do: I had a recent discussion with a random someone who posted about the utter lack of security in Ethereum that will ‘always exist because of the Turing completeness giving hackers an infinite amount of possible attacks.’

Well, I won’t get into it here but it’s fear-mongering. The part of the discussion that was enlightening though was when we started talking about layers of security and that is exactly what applies here. Let’s look at a non all-inclusive abstract list of layers that apply

Layer 1: Byte-code — This is the base layer of executable computer instructions.

Layer 2: Opcode — The grouping of bytecode into each logical process.

Layer 3: Source Code — The grouping of opcode in human written languages

Layer 4: Libraries — The grouping of source code instructions into common tasks

And this is where I want to stop for a second. This is where the hole for our last vulnerability was found. I’ll get back to this. Let’s go up some more layers

Layer 5: API’s — The grouping of libraries and custom source code that define an application platform

Layer 6: Service API’s — The grouping of API processes that produce a valuable, real world result

Layer 7: Applications — The grouping of Service API processes that deliver to the end user.

Right now a majority of our ICO raises have been to folks building at the API layer. There’s a problem though.

We are absolutely NO WHERE close to even REMOTELY having a suitable Library layer.

It is absolutely atrocious YET, we’re attempting to deliver and request value, I would argue, at the application layer when it comes to raising money.

Every raise is a Dapp and every stack up to the application layer is custom, which means the security is going to be hit or miss.

Why? Because nobody can reliably build anything above the library layer as a whole, so we develop our own library island and then build this application tower on top of that and hope it’s secure. So that leads me to two things:

1. Every single development team has an OBLIGATION to audit and vet common open source library code.

That code needs to be verified, STAMPED with authority, then posted as THE code to use for that group of tasks.

Need an update? Fine. Find a bug? Great. Let’s fix it and distribute community-wide. This area absolutely needs more leadership. Libraries are a grouping of a grouping of a grouping of byte-code and the consuming code will be a grouping of a grouping of a grouping of library code.

This layer is VITAL. Now I will use this to prop our team because this is exactly what we’re working on right now at Majoolr as we find our way into the system, and is exactly why we chose the name.

Qualified, modular code can ensure security for that set of tasks at the Library layer.

That is what we need. Not hodgepodge library contracts floating around that need revisions here and there. Actual, deployed, published, verified code, with a linkable address on every network. We have that at

https://www.Github.com/Majoolr/ethereum-libraries

It’s immutable? Yeah.. EXACTLY! And when it’s updated, we deploy the update and distribute the new address.

Users that want to update can link their next contract to the new address and POOF another step of progression. It’s not magic.. it’s science.

Now I said two things so I’ll go with number two after that rant:

2. When you build on an unstable layer, the higher you go, the harder the whole thing is going to fall.

That is what we just witnessed. My number two point is simply that we need to respect the security at lower levels. The impact is exponential. If you have a security gap at the byte-code level, that effects EVERYONE’s product.

Before we can release at the API layer, the service API layer, or obviously the application layer, we need to mitigate security risk increasingly at each lower level.

What about now: Investors, consumers, and users have to respect the risk they take now. Faulty code is unavoidable, period.

Hindsight is 20/20 and that goes for whether you did something your parents said would be bad or you put $50,000 in an Ethereum startup.

You accept this risk regardless of what the headlines or critics say.

Check out our website at majoolr.io, follow us on twitter @Majoolr, our libraries and contracts are posted and documented on github, if you have useful library code then SEND A PULL REQUEST