Creating a Web Authentication Mechanism on the Blockchain

We live in an era of convenience and anything that can reduce the time that it takes to complete simple tasks is embraced with open arms.

One of the most relevant examples in the online world comes from the realm of user authentication. Previously, we had to keep a collection of our user ids and passwords, now we can quickly and easily login through Facebook, Google and a whole array of other services.

But is this wise and are there better alternatives?

In this post, we will take a look at the current state of user authentication as well as some interesting alternatives that are now available due to blockchain technology.

Problems with The Status Quo

If you want to develop a restricted area for users on your website, you have to choose whether to develop your own unique system of the users’ identification, authentication, and authorization or use a ready-made solution.

That ready-made solution assumes that the user already has an account on some platform (Facebook, Yahoo, Google, Outlook, or even just an email). In this case, you simply use the appropriate mechanism (most often the OAuth 2.0 protocol) to verify that someone who tries to login to your site using an external user ID is that same user.

This option is easier to implement, but there’s a risk for the user. If something happens to his main account (for example, Facebook blocks the account for no reason), he’ll also lose the access to his information on your site.

Moreover, if I as a user want to log in to a site that I don’t trust yet, I’m faced with the need to give this site access to my personal information. This includes private information such as my name, e-mail or age. If the site only supports logging in with an external account, I face quite a tough choice indeed.

Either I refuse to use the site or sacrifice my privacy.

Most users usually end up sacrificing their privacy and anonymity thinking "Nothing bad can happen, I have nothing to hide." Unfortunately, the majority of attacks targeted at an unprepared user which end in monetary losses begin with words like:

“What can happen if I send this SMS code to a bank employee?” or “Is it really that bad to send these request headers to a tech support employee?”

Usually, one learns the answer to such questions when it is too late.

How Ethereum Can Help

We’ve already understood that there are three main problems:

• The user is not obliged to trust the website he visits and wants to avoid the leakage of his personal information
• The site wants to use an external authentication system to avoid storing user data and the associated security expenditures
• The existing external systems providing sites with the ability to authenticate users carry the danger of censorship. Any account can be blocked at any time without explaining the reasons for it and often without the possibility of recovery

However, could we use a secure and decentralised network such as Ethereum’s in order to aid this type of authentication.

It is after all a cryptographically secure keys pair in which the public key represents the wallet address, and the private key is never transmitted over the network. Moreover, it is known only to its owner and it is possible use asymmetric encryption to authenticate users.

In the simplest case, we can use the Ethereum wallet address as a user ID. However, if the user loses access to their key then they also lose access to the system forever.

Similarly, if your key is somehow compromised and a hacker is able to get hold of it, then you cannot use that same key to verify ownership anymore. The hacker could merely masquerade as yourself on all the sites you sign up for.

EtherAuth Implementation

There was an interesting proposal that was presented by the MixBytes team at one of the most recent Ethereum hackathons. This was their EtherAuth smart contract engine.

EtherAuth is an attempt to make a decentralized site login and authentication protocol. It’s analogous to the “Log In with Facebook” button that you have probably become accustomed to. It is a smart contract that will store user IDs and their associated wallet addresses

The user ID is simply a UTF-8 string with size ranging between 2 and 32 bytes. The user himself creates it on inception of the wallet and will later use it to enter any site that supports EtherAuth.

It would also be possible to add a restriction on the possible characters included in the string. One could restrict it to Latin characters and Arabic numerals (subsets of 7-bit ASCII encoding) in order to limit the possibility of creating visually similar IDs.

When creating an account with EtherAuth, a pair of keys is created. You will create an authorization key (authAddr) and a key to restore access (recoveryKey). The name “recoveryKey” is perhaps not the best since this address is used to manage the account and not merely for recovery.

When created, both addresses are the same as the address of the wallet which first made the transaction. Users who care about their security should create a separate Master Key and store it in a place that is inaccessible from online.

It is perhaps safest to store this on a piece of paper in a cold storage. Paper storage relies on what is called a recovery seed. Recovery seeds are a set of 12 mnemonic words that when used can recreate the key pairs for your wallet.

If you are going to be using a wallet for authentication then It’s also recommended you use a separate address from the one that keeps all of your Ether. Doing this allows you to avoid any hackers from tracing your Authkey to the wallet with your assets. For now, you cannot create a separate authKey and recoveryKey when creating an account. This is something that could be updated in later iterations of the smart contract. If you wanted to further protect yourself then you consider VPN services.

Using EtherAuth

There is a dedicated web page intended for the user’s interaction with the smart contract. You can create an account there, change the keys or delete it. To work with it, the user will need to install the well-known browser plugin called MetaMask.

Of course, if you are already quite an avid user of the Ethereum network then you will already have used MetaMask and will probably have an idea of how it interacts with the network.

The overall user authentication process using EtherAuth looks like this:

• The site (backend) contacts the smart contract and receives the user's Ethereum address
• The site (backend) generates and records a message, and asks the user to sign this message with the help of the authKey address
• The user being on the site (frontend) signs the message using the MetaMask plugin and sends it to the backend
• The site (backend) verifies the signature, and if everything is alright, it activates the user's session

It is important that authentication checks should take place in a user-uncontrolled environment. So, in other words, all of the checks should be completed on a server instead of on a user's browser.

Among the problems, you may encounter is the signature verification in the frontend part. Not all browsers support elliptic curves. It can be resolved by adding a function to the smart contract that returns the "ecrecover" result from the message.

As a result, you have a viable proof-of-concept of a decentralized authentication system based on Ethereum and used on the MetaMask plugin. This system still needs several modifications to be able to provide user anonymity. The user has the opportunity to restore access in case of his primary key loss (but not in the case of a recovery key loss).

The decentralized system is not subject to censorship of the large entities, such as Google or Facebook. If it is necessary to censor something, each website should implement it independently. Yet, this would only affect the user’s interaction with that site and not any others.

The Ethereum network currently has pretty slow transactions speeds (when creating an account, the user may have to wait a few minutes), but sites can get the data and verify users quite quickly.

This solution scales well, because there’re a lot of data nodes, and anyone can add another one at any time. The complexity of implementing such a solution for site owners is no higher than the complexity of implementing OAuth 2.0.

Conclusion

It is important to note that this is still the early stages of the project and it was only recently proposed at the hackathon.

Moreover, the adoption rates for Ethereum and cryptocurrencies in general is still only a fraction of those who use the likes of a Facebook and a Google. It will take some time before people will feel more comfortable using an Ether address than their Facebook account.

However, crypto adoption rates are indeed growing and the recent data scandals at Facebook have helped to alienate a large number of people. It will be interesting to see whether decentralised authentication can be a viable alternative.