## Understanding and Verifying Web3 Signatures: A Practical Guide Interacting with Web3 applications often requires you to "sign" messages or transactions using your crypto wallet. This act of signing is akin to providing a digital signature, authorizing actions or confirming your identity. However, malicious actors can exploit this process. This lesson introduces a critical security practice—verifying what you are signing—and a tool to help you master this skill. The primary resource we'll explore is **`wise-signer.cyfrin.io`**, a platform developed by the Cyfrin team. Its purpose is to train users to meticulously inspect signature requests and transactions before approving them, thereby enhancing their Web3 security. You can access the training by visiting the website and clicking "Start Training Now" or navigating through "Play Now" to the "Simulated Wallet." ### The Critical Importance of Verifying Signature Requests When a decentralized application (dApp) wants you to perform an action or log in, it will often present a "signature request" via your wallet (e.g., MetaMask). It's crucial to understand that not all signature requests are legitimate or what they seem. A common attack vector is **domain spoofing**, where a malicious request is disguised to look like it's coming from a trusted source. Let's examine a practical example from the Wise Signer platform's simulated training environment (specifically, Question 3 of 15). **Simulated Scenario: Signing into OpenSea?** Imagine the following prompt: "3. Sign or reject this signature. Assume your wallet address is `0xf39Fd6e51aad88F6F4ce6aB8827279cffFb92266`. You want to sign into Opensea to see your NFTs. Will signing this accomplish that? If so, please sign, otherwise reject." In the simulation, you're presented with what appears to be the OpenSea website. Clicking a "Sign in with Ethereum" button triggers a pop-up designed to mimic a MetaMask signature request. **Analyzing the Simulated MetaMask Pop-up** At first glance, the pop-up might seem legitimate: * **Signature Request From:** `opensea.io` This initial field suggests the request is indeed from OpenSea. However, the devil is in the details, specifically within the **Message to sign**: ``` app.gnosispay.com/ wants you to sign in with your account: 0xf39Fd6e51aad88F6F4ce6aB8827279cffFb92266 URI: https://app.gnosispay.com Version: 1 Chain ID: 100 Nonce: 8dc50dhp767cf54o1uptoe76v2r Issued At: 2025-05-13T03:01:56.815Z ``` Notice that your wallet address (`0xf39Fd6e51aad88F6F4ce6aB8827279cffFb92266`) is correctly included in the message. **The Red Flag: Domain Mismatch** Here lies the critical discrepancy. Although the pop-up initially claims the request is from `opensea.io`, the actual **Message to sign** and the **URI** field explicitly state `app.gnosispay.com`. You intended to sign into OpenSea (`opensea.io`), but the signature you are being asked to provide will actually authenticate you or authorize an action on `app.gnosispay.com`. This is a classic example of **domain spoofing**. The attacker is trying to trick you into believing you are interacting with OpenSea, while the signature's effect will be on a completely different domain. A legitimate sign-in request from OpenSea would look different. For instance, a real MetaMask pop-up for an OpenSea sign-in would typically state: * "Request from `opensea.io`" * Message: "`opensea.io` wants you to sign in with your account: `0xYOUR_WALLET_ADDRESS...` Click to sign in and accept the OpenSea Terms of Service (`https://opensea.io/tos`) and Privacy Policy (`https://opensea.io/privacy`)." * URI: `https://opensea.io` The crucial difference is that all domain references consistently point to `opensea.io`. In our simulated scenario, you should ask: "Why is OpenSea (or what appears to be OpenSea) trying to have me sign a message for `gnosispay.com`?" This mismatch is a major red flag. The correct action is to **reject** this signature request. **Consequences of Incorrectly Signing** If you were to mistakenly click "Sign" in this simulation on Wise Signer: An alert would inform you: "You signed something you shouldn't have! Oops! You allowed this site to impersonate you on Gnosis Pay!" Further feedback would clarify: "That's incorrect. Let's see why: You should reject this signature! Even though you're on what appears to be OpenSea, the signature is requesting you to authenticate with `app.gnosispay.com`, not `opensea.io`. This is a common phishing technique called 'domain spoofing' where the attacker presents a message that looks legitimate but actually authorizes login to a completely different website." The platform also emphasizes: "Notice the mismatch: The website appears to be `opensea.io` (as shown in requestFrom), but the signature message is requesting authentication for `app.gnosispay.com`. This is a major red flag." ### Key Takeaway for Enhanced Web3 Security The most critical lesson here is to **always meticulously check the actual domain specified within the message content and URI field of any signature request.** This domain must match the website or service you believe you are interacting with. Discrepancies, like the one shown between `opensea.io` (the apparent source) and `app.gnosispay.com` (the actual domain in the message), are tell-tale signs of phishing attempts or domain spoofing. Tools like `wise-signer.cyfrin.io` provide an invaluable, safe environment to practice spotting these deceptive requests. By honing your ability to verify different types of signing requests and transactions, you significantly bolster your defenses against common Web3 threats and protect your digital assets. Make it a habit to scrutinize every signature request before you click "Sign."