Authereum: Improving Authentication on Ethereum
The problem
Non-custodial authentication schemes are a big user experience challenge for onboarding new users onto Ethereum. The current mechanisms involve the end user either having to copy and backup a seed phrase, or encrypt a keystore file, store it on their computer, and pray to a higher entity that they didn’t lose their passphrase for decryption when they forget their password. The user experience gets worse on mobile when the user is required to retype a 12 word mnemonic seed phrase. Most people still rely on memorization of passphrases and less than a quarter use password managers. It’s evident that current user experience is anything but pleasant.
Mainstream adoption of Ethereum and blockchain is being impeded by usability problems such as causing the user to deviate from current flows and processes that they are accustomed to. Unpleasant user experience leaves a bitter taste in the user’s mouth and makes them less likely to try again in the short term.
The standard web 2.0 user doesn’t care about decentralization, doesn’t want additional hurdles to the user experience, and prefers convenience over privacy. The current user experience requires the user to download browser extensions, be alerted with a popup every time a transaction needs to be made, sign data they probably don’t understand, and even think about gas. All these perplexities need to be abstracted away to provide a smooth as butter user experience. Don’t make the user think.
Improving current processes
Decentralization and privacy is a spectrum. On the completely centralized end of the spectrum, the user has a decent user experience with current systems such as logging in with Twitter or Google. On the opposite end, the user is entirely responsible for their own keys, such as generation and storage, and also responsible for managing their own multi-sig contracts, deploying their own contract based wallets, figuring out gas requirements, etc.
If the user loses their keys they are out of luck.
A standard user doesn’t want additional responsibility and will always prefer convenience over maximum decentralization if given the choice. We can onboard the user by holding their hand initially.
Expecting users to understand key management and how transactions work during the onboarding process without holding their hand first is like expecting someone who has never ridden a bicycle to learn without training wheels.
We can make it easier by holding the user’s hand and giving them the opportunity to remove the training wheels once they understand and are comfortable with the required level of knowledge to interact seamlessly with the ecosystem.
Making a compromise between usability and full decentralization is required for usable systems that don’t scare users away but also provide them with full control and ability to opt-out of any hand-holding system when their knowledge is mature enough in regards to key management.
Contract-based accounts
By onboarding new users with a contract-based account to manage their funds, we can provide users with additional layers of security. Each account backed by a smart contract behaves similarly to an access control list (ACL). In the context of web, ACLs maintain permissions attached to objects used to authenticate users trying to access resources. In the context of contract-based accounts, the ACL is the smart contract that maintains a structure of which keys can access which methods. Essentially, there’s the ability to have keys that can authenticate certain types of transactions going through the contract-based account.
This process is analogous JSON web tokens (JWT) where the token contains all the information the server needs to authenticate the request such as expiration timestamps and payloads. In contract context, the token is a signature of an attestation made by an authentication device key.
The authentication device can be a smartphone. The auth app on the device generates a new key pair and is whitelisted by the account contract. This newly generated auth key has root privileges to the contract and can authorize new devices.
As an example, when a user visits a dapp in their browser a new ephemeral key pair is generated and a request is sent to the auth device in form of a push notification to sign the ephemeral key (or more contextually termed login key) by the auth key on the device. The auth app is recommended but not required; the user can store auth keys on their browser and receive auth key signing requests through email confirmations.
From the user’s perspective, the process resembles a familiar web 2.0 experience. Here’s visually what the process looks like for signing a login key by an auth key:
The login key is hashed and signed by the auth key and after that the user can sign transactions seamlessly with the login key. The signed transaction along with the signature of the login key by the auth key is sent to the account contract, verified, and processed. Thanks to the addition of the create2 opcode to the EVM, deterministically computed addresses for contract-based can be done meaning that a smart contract can be generated for new users but only deployed once funds exists and the sender deploying the contract is refunded.
To help conceptualize the process, here’s what the transaction processed by the account contract looks like:
Meta transactions
The processes previously described involves Meta Transactions. The transaction is first handled by a secondary network of meta transaction relayers where they are responsible for verifying the transaction and signatures, and paying for the actual gas by signing the transaction before broadcasting it to be processed by the account contract. The beauty of meta transactions lies in the matter that the relayers (anyone who signs and broadcasts on behalf of the user) are refunded their gas cost and optionally paid out a fee for their service. The gas cost may also be paid in the form of a token depending on the implementation.
ENS
Integrating ENS (Ethereum Name Service) allows users to register accounts using a human readable username. A user can register using a username and password as they’re used to, but in this case, the username is tied to an Ethereum account. Universal Login is a good first implementation of this pattern.
In the context of Authereum, a login confirmation email is sent when a user attempts to log in using an existing username and a password — this email is sent to the email address belonging to the ENS name. All the user has to do is open the email in their browser where the auth key lives and sign the login key with the auth key. If using the app the user receives a push notification and confirm or reject the request on the app. We demonstrated an example of using ENS for web 2.0-esque authentication at the ETHNewYork hackathon (and won an ENS integration prize).
Account Recovery
Something that doesn’t settle well with standard users is the fact that losing their keys means they’re screwed. The ability to recover a lost account is a possibility with contract-backed accounts because the funds are tied to a contract and not to a single key. Each account contract has the ability to add new accounts to that have permissions to act on the contract and its funds.
Argent is a good example of a contract-based account that allows you to have guardians which are trusted friends and family members to be able to lock your account in case you lose your device as well as the ability to add new authorized devices to your account contract.
Torus allows anyone with a Google account to have their own wallet which works by sharding a private key that’s generated upon first login to multiple Torus nodes. When the user signs in again, the frontend fetches all the key shards to reconstruct the private key.
Authereum can utilize Torus as a mechanism for recovering an account by adding the Torus account as an authorized device on the account contract. This makes it possible so that when you forget your Authereum login, you can login with Google via Torus and sign a transaction to add a new device to the contract-based account.
Web 2.0 Security
Currently when you login on Google for example using a different fingerprinted browser or device, you get an email notification and the option to deny the authentication request. This security process can be implemented in Ethereum authentication schemes by having all transactions signed by the login key go through a server which does the security checks. If everything checks out then the server can sign the message as the role of a guardian and broadcast it. The account contract checks that the transaction includes the signature of the guardian server, otherwise deny it.
This is still completely non-custodial because the user can, at any point, submit transactions using their auth key, effectively bypassing any firewalls implemented on the Authereum layer. The security server acts as a firewall because it can deny any meta transactions that don’t meet security standards either set by the provider or user, such as denying transactions coming from blacklisted devices or IPs or denying transactions that involve blacklisted contracts and accounts. The user also has the ability to whitelist IPs or add additional requirements the meta transaction request must meet in order for it to be signed by the guardian server and to be broadcasted. This area is where we think offers the user a great deal of peace of mind and plan on expanding on.
Fiat on/off ramps
The onboarding process for users to acquire ether using fiat is another challenge. Authereum is collaborating with Abridged, an application development toolkit, to integrate off-chain payments and fiat off-ramps through Wyre. This will allow users to purchase ether using standard credit cards and immediately be able to transact value with other users in the Layer 2 network without fees. We’re looking into the possibility of having Authereum be an option in WalletConnect to allow users to login to exchanges such as Binance with Authereum and send their withdrawals directly to their contract-based account.
Conclusion
Contract-based accounts allow the user to secure their funds with ease-of-mind by allowing tiered keys to act on the contract depending on their permission levels and attestations by higher tiered keys. Authereum is a fully non-custodial login process that utilizes ENS and web 2.0 style security to enable an onboarding experience that aims to reduce friction by providing new users with training wheels and abstracting away complex interactions that they are not accustomed to while still not deviating from decentralization principles.
Upcoming posts will include further implementation details. Stay tuned!
Many thanks to Chris Whinfrey and Shane Fontaine for helping put this together, and thanks to the Abridged team for helping us get up and running with contract based accounts.
Please follow us on Twitter @authereum and subscribe to our newsletter for future updates.
Thanks for reading!
Update
We’ve improved the key management architecture. Check out the latest details here:
https://medium.com/authereum/authereum-key-architecture-explained-8e0781cf3ea0
