Exploring Security Checkpoints in Sign-In-with-Ethereum Based on EIP-4361 by Fairyproof
As the narrative of metaverse[1] develops, people begin to envision developing an innovative method to allow users to interact with either…
As the narrative of metaverse[1] develops, people begin to envision developing an innovative method to allow users to interact with either web 2.0 applications or web 3.0 applications via a uniform interface. Thus, a new sign-in model i.e. Sign-In-with-Ethereum (SIWE)[2] has been proposed and gained increasingly more traction.
When we talk about signing in to an application people would intuitively think about signing in with a username and a password. This is a typical sign-in method adopted by nearly all web 2.0 applications or platforms including internet giants such as Facebook, eBay, Amazon, and more. However, this method is exploited by these giants to make our online experience more toxic and employ our online data for business profits without authorized permissions from users.
This is a big complication web 3.0 applications or protocols are trying to fix. And thus, using an Ethereum wallet to sign in has been proposed. And a web 3.0 application [3] is trying this proposal.
A significant feature of SIWE is that when a user logs in to an application or platform, he/she no longer needs to type a user name and a password that he/she has set for that application or platform, what he/she needs to do is to use his/her Ethereum wallet e.g. MetaMask[4] to log in.
Under this mechanism, a user can use his Ethereum wallet to uniformly log in to any web 2.0 or web 3.0 application, platform, or protocol.
In general, to provide a better user experience, a web 3.0 application which consists of at least one or multiple smart contracts wouldn’t just expose the interfaces of its smart contract(s) to users but would wrap the smart contract(s) in a conventional web 2.0 application with a client-side and a server-side such that user would directly interact with the C/S app. So, for the convenience of description, we will use “C/S app” in the following paragraphs to uniformly refer to a web 2.0 or web 3.0 application.
When using an Ethereum wallet to log in to a C/S app, a user can be pseudo-anonymous and will not leave his/her social identity or profile in the application. This will greatly protect users’ privacy and interests from being exploited.
To better push and propagate the implementation of this innovative idea, an Ethereum Improvement Proposal EIP-4361[2] was proposed in October 2021.
This EIP describes the format, fields, rules, security mechanisms, etc that a message is proposed to follow for an Ethereum account to sign this message to authenticate with an off-chain service.
This EIP contains details in these areas: how SIWE works, the format and fields of a SIWE message, how to resolve ENS data, guidelines for implementation of a C/S app, and guidelines for implementation of an Ethereum wallet.
As a blockchain security company, Fairyproof is especially interested in SIWE’s workflow and the guidelines for implementations of both a C/S app and an Ethereum wallet because this EIP introduces an innovative log-in method that will bring significant changes to the existing implementations of C/S apps and Ethereum wallets if it is adopted and implemented. And these changes will very likely introduce new security checkpoints a security company needs to be aware of.
Before we proceed, we need to first understand SIWE’s workflow:
The above diagram shows how SIWE works. In this process, the wallet and the C/S app perform the major verification work and drive the process to move forward. They play key roles in safeguarding the security of the whole process. In addition, there are other general security issues or risks that need to be addressed in the proposed SIWE mechanism.
We studied this EIP and will explore and analyze the key security checkpoints in the wallet, the C/S app, and some genera security areas in the following paragraphs.
1. Checkpoints in Wallet
With regard to the wallet, based on the EIP, the major responsibilities it performs include verifying the message, verifying the domain name, and displaying terms and descriptions for the login.
From Fairyproof’s point of view, among these responsibilities, a significant checkpoint is checking whether or not the domain term is matched when the wallet processes a signing request.
This is to prevent a phishing attack. By checking this it ensures that the C/S app which the user is visiting is the one the user intends to visit. For instance, if the user intends to visit Opensea.io, the wallet needs to ensure the user signs a message coming from Opensea.io instead of a domain like openseaxxx.xxx.
Besides this security check, the following regular checkpoints should be checked as well:
- whether or not a SIWE message contains the fields defined by the EIP,
- whether or not the SIWE message conforms to the ABNF format,
- whether or not a corresponding EIP such as EIP-191 or EIP-1271 is used to verify a signature,
if ENS is resolved, whether or not the data fields are verified.
2. Checkpoints in C/S App
Concerning the C/S app, based on the EIP, the major responsibilities it performs include verifying the message, creating sessions, and interpreting and resolving resources.
From Fairyproof’s point of view, among these responsibilities, a significant checkpoint is checking whether or not the nonce generated by the C/S app is appropriate. A nonce should be generated per session to prevent a replay attack.
Besides this security check, the following regular checkpoints should be checked as well:
- whether or not a SIWE message it composes contains the fields defined by the EIP,
- whether or not the SIWE message conforms to the ABNF format,
- whether or not sessions are bound to the Ethereum address that performs the signing,
whether or not the format of the resources conforms to RFC 3986.
3. Checkpoints in General
Besides the checkpoints in both the wallet and the C/S app, in the workflow, there are multiple communications among these parties, therefore using security mechanisms such as HTTPS to ensure secure communication is a must-have check as well.
Closing Thoughts
All the above-mentioned items are what Fairyproof is aware of and studying. These items are what we should check when auditing a wallet or a web2.0/web3.0 application if it implements this EIP.
References:
[1] Metaverse, https://en.wikipedia.org/wiki/Metaverse, March 15, 2022
[2] Sign-In with Ethereum, https://eips.ethereum.org/EIPS/eip-4361, October 2021
[3] login.xyz, https://login.xyz/
[4] MetaMask, https://metamask.io/, 2022
Join Coinmonks Telegram Channel and Youtube Channel learn about crypto trading and investing