Using Ethereum and Metamask for Website Authentication

Web Services

By far the most common approach to web-authentication is to use HTTP+HTML form-based authentication / cleartext protocol. The popularity of this technique, despite it’s obvious security shortcomings, is probably due to webmasters (or their employers) wanting fine-grained control over the look and behavior of their login pages; that is, since the default pop-up dialog box for digest access authentication does not allow customization on many web browsers, web-service providers, from online banking sites to social media, use simple HTML forms, and rely on the SSL transport to provide security.

The Ethereum Wildfire Project is proposing a new web-authentication mechanism that is just as simple and configurable as HTTP+HTML form-based authentication, but much more secure. It would leverage the MetaMask chrome extension.

The best part of this new authentication mechanism is that it addresses a common pain point for users: remembering passwords.

A typical web-savvy millennial will have accounts with between twenty and fifty web-services, including online merchants and credit card companies that have access to financially sensitive information. More often than not people use the same password on multiple sites — which is of course a great boon to phishers. Anyone who is at all security-conscious will use a different password for each web-service account. And that’s a whole different pain…

Who can remember all those passwords?

Ethereum Tools Have an Answer

  1. Install MetaMask (or a similar Ethereum tool)
  2. Your account address is your username
  3. When you login to a web-service, you’re presented with a message to sign
  4. The web-service authenticates you by checking your signature

No usernames; No passwords; No hassle. It uses HTML form-based authentication, with some minor JavaScript code to interface with MetaMask — So login pages can be customized.

This type of login will bring Ethereum and MetaMask to millions of new users; and it will bring web3-aware back-end processing to thousands of web-service providers. And while it will act as a gateway to Ethereum for millions of users, the actual logging-in is conducted off-chain (it’s just signing a message), so it doesn’t cause any congestion of the Ethereum network.

How Does it Work?

The magic that makes the MetaMask login system work is in Ethereum’s Keccak hash signature algorithm. Ethereum account addresses are actually the lower 160 bits of (a hash of) the public-key from a private/public key-pair. These keys are not used for encryption — recall that Ethereum transactions are not encrypted; they are signed— or more accurately, a keccak hash of the transaction is signed using the private key. The keccak hash is a one-way function; that is to say, it is impossible to recover the transaction data from the keccak hash (or the signature). However, the keccak hash, together with the signature can be passed to through a function called “ecrecover” to recover the public key, and thereby recover the originating Ethereum account.

The keccak hash / signature algorithm is central to the Ethereum eco-system: Ethereum smart contracts have access to both a keccak hashing function and an ecrecover function; popular Ethereum tools, such as MetaMask have the ability to keccak-sign both Ethereum transactions and arbitrary messages; and popular Ethereum javascript libraries have the ability validate keccak signatures. We can leverage all these tools to bring password-less logins to web-service providers.

Benefits to Web-Service Providers

Selling web-service providers on MetaMask authentication is not as tough as you might think. For one, the web forms that most online services currently use would not need to be modified very much — They still control the basic solicitation of user credentials — except that a few fields would be now be auto-populated. And the backend code to authenticate a MetaMask login is straightforward. For their users who authenticate with MetaMask, service providers would not need to keep track of when a user last “changed their password”, nor would they need to handle forgotten passwords, nor would they need to enforce password complexity rules. But perhaps the biggest reason for web service providers to adopt Ethereum-based authentication is that many are searching for some way to get involved in crypto-currencies.

Ultimately

Ultimately, of course, as Ethereum enthusiasts we hope to see Web service providers accept Ether payments for their services. Ethereum-based authentication can be the gateway for this functionality. For example, consider Joe’s Porn Store (a colorful example): Currently, after customers pay a fee for their membership, the backend server issues a password, which is sent to the customer via email. With MetaMask authentication however, the customer pays with Ether, and their account is extracted from the payment transaction. From then on the customer only needs to prove that the account is theirs (by signing a MetaMask login message). Once you allow a user to register using his Ethereum address as a username, it’s only a short stretch to let them pay their registration fee with Ether, and then pick the address out of the transaction.

Where Do We Fit

This is all well and good, and maybe you’re already convinced, dear reader. But if nobody takes it upon themselves to push web-service providers, then nothing will change. We believe that the most effective way to promote this login technique is via corporate adoption — so that people will be required to use the MetaMask login technique at their workplaces. Therefore, the Ethereum Wildfire Project is gearing up to submit an Internet Draft to the IETF, in order formalize an EAP authentication algorithm, similar to EAP-CHAP (Challenge Handshake Authentication Protocol). This specification will formally require using ECDSA / Keccak hash, and the use of an account number, recoverable from a challenge-response (in practice this will be a MetaMask signed message) via ecrecover. At the same time we plan to submit a module supporting EAP-KECCAK to the FreeRadius project (which supplies a very popular, free, open-source RADIUS server). While the foregoing is necessary in order to get RADIUS servers to support the the MetaMask login initiative at the enterprise level, we will also generate sample code, make promotional videos, and provide consulting to web-service providers who are willing to adopt the Ethereum-based login techniques. Check out our website to learn more about how we’re going to evangelize this technique, and some of the other authentication tasks we can accomplish with similar techniques, and how you can support our efforts.

Ethereum Wildfire Project