1 6.858 Final Project: Distributed Authentication on the Ethereum Blockchain Michael Shumikhin, Sarah Wooders, and Ryan Senanayake Abstract— We introduce KeyChain, a trust- less authentication system which stores user- name to public-key mappings on the Ethereum blockchain. Keychain includes ann account re- covery feature, where users set up a “web of trust”, where users can authenticate other users via the mapping and recover their accounts if k of n members of their web of trust approve. We implement a prototype of Keychain using an Android app to control a user’s account and store keys, a Node.js app as an example application to authenticate with KeyChain, and the Ethereum blockchain to record name/key mappings and the user’s web of trust. I. I NTRODUCTION The current state of digital authentication requires significant trust in 3rd parties. Users need to trust websites to store their pass- words safely. Websites need to trust users to choose secure unique passwords, which the majority of users will not do. And even for the minority of users who do, their account can still be compromised by trusting recovery emails, computers with malware, companies, etc. KeyChain aims to improve upon current authentication systems with the following fea- tures: • Trust-less authentication Users do not need to trust KeyChain or any websites they authenticate with. • No passwords: Confirmation on a trusted device provides access. • One account: One KeyChain account al- lows for access to all website accounts • Safer recovery: Users can recover for- gotten private keys or revoke access for compromised keys without compromis- ing their security by relying on recovery emails or security questions. Recoverability is a crucial aspect of a useable authentication system. If it is too difficult for a user to recover from losing or forgetting a secret, there will be no adoption of a system even if it is more secure. This is an issue with public-private key encryption, which offers no ability to recover from a lost private key file. Below is outlined a comparison of our sys- tem with a few different methods of authenti- cation: A. Website stores hash of password A User has to trust the website to store their password correctly, which often is not the case and results in key compromise. Web- sites also trust that users will choose unique, high-entropy passwords, which for the large majority of users is not the case. Additionally, many sites will provide a forgot your password option, which relies on security questions or a recovery email, both of which may be even less secure than the password. B. Sign in with Google, Facebook, etc This requires trusting the company behind the authentication platform, which may not be a big deal for the majority of users, but it does mean that there will likely never be one solution that everyone uses. For example, Ap- ple would probably not like the idea of trust- ing Google for their authentication system. Additionally, these systems still rely on the user picking a unique, high-entropy password. Best practices also dictate that a user make these hard to remember passwords different. While it is easier for a user to make one good password, it is often easier for a user to make a memorable username which may be protected with public key cryptography. C. Providing public key to website While this is a much more secure system, if you lose your private key it is not possible to recover. Furthermore, this is not a prevalent