Authentication: Ethereum and Smart Contracts

Bitcoin took the world by surprise in the year 2009 and popularized the idea of decentralized secure monetary transactions. The concepts behind it, however, can be extended to much more than just digital currencies. Ethereum attempts to do that, marrying the power of decentralized transactions with a Turing-complete contract system. In this post, we teamed up with Ivo Zieliński, Konrad Kozioł, David Belinchon, and Nicolás González from GFT's Innovation Team to develop a practical application of an Ethereum-based login system for Ethereum users. This system will allow any Ethereum user to prove ownership of an Ethereum account without using his or her private-key each time such proof is required, which is ideal for login systems. Think of "Login with Facebook" for Ethereum users. Read on!

This is the third post from a three-post series about Ethereum. Read Part 1 and Part 2 (which we here at DZone subdivided further into Part 1, Part 2, Part 3, and Part 4) if you haven't done so.

Introduction

In our previous post, we took a closer look at Ethereum, a decentralized, Turing-complete platform for developing applications using a blockchain. In Ethereum, applications run on each node in the network. The results of those computations are then encoded in blocks, which, through the proof-of-work system, are validated by each node in the network. Furthermore, these operations (transactions) are carried out on behalf of users. Users must sign each transaction with their private-key, thus making it possible to track whether a certain user can perform certain operations or not. In particular, transactions have a cost, and users must be able to pay that cost by spending Ethereum's cryptocoin: Ether.

In our previous post, we also had a look at some practical applications of Ethereum. The Decentralized Autonomous Organization (DAO), a central bank, a crowdfunding system, a proof of existence system, and even our own simple authentication system. All of these examples run without a central authority holding any control over them. All operations are carried out by each node on the network, and these are only effective after all nodes agree on the results. This makes Ethereum particularly powerful for applications where no single entity must be able to validate or approve operations.

Our simple login system on Ethereum did work as expected, but it was less than ideal. Let's take a look at how it worked:

The objective of the system is to make it possible for any third-party to allow users to log into their website using an Ethereum address as an identifier. No username or password is required. We assume a user attempting to log in with an Ethereum address is a user who currently holds an Ethereum address with some Ether (that is, a user that holds an Ethereum account for other uses). Based on these assumptions, this is how our sample system worked:

1. A user browses to a third-party website that requires a login. An input text area for the user's Ethereum address is displayed.
2. The user inputs his or her Ethereum address and clicks "login."
3. The third-party backend produces a challenge string and signs a JWT with the challenge embedded in it.
4. The user sends the challenge string to the login method of the Login contract already available on Ethereum.
5. The backend watches the Ethereum network for the challenge string. It must be sent by the owner of the Ethereum address that was input in step 2.
6. If the challenge is seen by the backend within a reasonable timeframe, the user is then marked as logged in using the Ethereum address from step 2 as the identifier. A new JWT with full access to the third-party website is issued.

There are a series of problems with this approach. Namely:

• The user must manually make a call to the login method of the Login contract using an Ethereum wallet of his or her choice.
• The user must know the address and the interface of the Login contract beforehand.
• The user must spend some Ether to log in because the contract relies on events that are logged to the blockchain (that is, they perform writes). This makes the contract require gas to run.
• The backend must wait for a new block to be mined and propagated through the network before the login is completed (minimum latency in the order of 12 seconds or more).

As you can imagine, these limitations make our simple authentication example impractical. So what can we do about them?

Towards a Practical Authentication Solution for Ethereum Users

My team at Auth0 joined forces with the guys from GFT's Innovation Team to think of a better way of using Ethereum for this purpose. We came up with a proof of concept which we will share with you in this post. First, let's describe the design goals for our system:

• It should allow users with an Ethereum address to use that address to log in to a third-party website (that supports this login method).
• It should be easy to use and reasonably easy to setup.
• It should not compromise the security of the user's Ethereum account.
• It should allow users to recover their credentials in case of loss or theft.
• It should not require knowledge of contracts or manually calling contract methods.
• It should have reasonable latency for a login system (no more than a couple of seconds).
• It should not cost users gas (or money) to log in.
• It should be reasonably easy for developers to implement in their apps.

One of the biggest problems with our initial approach was that writes were necessary. This forced users who wanted to log in to spend Ether to do so. Worse, they had to wait for confirmation of the transaction before the login was successful. On the other hand, this made the login process truly decentralized.

Writes were a requirement for our previous system due to the way Ethereum events work. Events are special operations in the Ethereum network that can be watched by nodes. Internally, events are Ethereum Virtual Machine ops that create data that is added to the transaction when it is mined. Events do not work on read-only (constant) Solidity functions since they are added to a transaction when it is mined. This forces users of our first system to pay to generate a LoginAttempt event.

This limitation forced us to make a compromise: rather than remain entirely decentralized, we added a server to handle authentication requests. In turn, this server relies on data stored in the Ethereum blockchain. However, our system does retain the ability to allow for serverless logins. We will see how that works later on.

Another big limitation of our first system was that the user needed access to his Ethereum wallet to log in. This is impractical for several reasons:

• Users usually keep a single wallet. In other words, they do not carry around their private keys to easily use them on different devices.
• If a user loses his or her Ethereum private key, he may never be able to authenticate again with that address to a third party service, not even to switch his main address or recover his information. This poses a problem for long-term use of the system.
• Requiring a user to use his or her private key for each login can be a security issue for accounts holding big amounts of value. For those accounts, private keys may be stored safely and used only when necessary. Requiring their use for each login is less than ideal.

So some way of using an Ethereum address to login without requiring the private key for that address must be implemented for our new system.

Tune in tomorrow to find out how!