Signature Login and Replay Protection: nonce, Domain, and Expiration Time

This article has three layers:

1. Layer 1: The Intuition: What is a replay attack
2. Layer 2: Real-World Use: SIWE, cross-chain replay events, API signatures
3. Layer 3: Principles and Engineering details

Layer 1: The Intuition

1.1 Replay Attack

You present a signed slip to a security guard: "Please let me in." The guard verifies the signature and lets you through.

The problem is: if someone nearby photocopies this slip and presents it again tomorrow, the guard verifies the signature, finds it is still valid, and lets them in as well. The signature itself wasn't forged; it was simply reused. This is a replay attack.

1.2 How to Prevent It

Add a few more details to the slip:

Layer 2: Real-World Use

• Sign-In with Ethereum (EIP-4361): The standard format for logging into websites using an Ethereum address. Wallets parse key fields (especially the domain) and display them prominently; if the domain does not match, a warning is issued.
• The Ethereum and Ethereum Classic Fork (2016): After the fork, the transaction formats of the two chains were identical. A transaction signed on ETH could be taken as-is and executed on ETC, causing many people to "mysteriously" transfer funds on the other chain. The subsequent EIP-155 included the chainId in the transaction signature, closing this loophole.
• Cloud Service API Signatures: AWS request signing (SigV4) includes the timestamp, request path, and service region in the signature; requests exceeding a few minutes are rejected directly.
• Payment Interfaces: Payment callbacks usually include an order ID and a timestamp. The server records processed order IDs to prevent the same callback from being credited multiple times.

Layer 3: Principles and Engineering

3.1 What an SIWE message looks like

example.com wants you to sign in with your Ethereum account:
0x5aAeb6053F3E94C9b9A09f33669435E7Ef1BeAed

Bind this address to your account.

URI: https://example.com
Version: 1
Chain ID: 1
Nonce: 8f3k2QpZ7mXw
Issued At: 2026-11-05T10:00:00Z
Expiration Time: 2026-11-05T10:05:00Z

3.2 Server-side Verification Checklist

1. The nonce must be generated and recorded by the server, bound to the current session, and invalidated immediately after use;
2. The domain and URI in the message must be your own;
3. The current time must be between Issued At and Expiration Time;
4. Use ecrecover to recover the address from the signature; it must match the address in the message;
5. Smart contract wallets (like Safe) do not have a private key; you must use the contract's isValidSignature via EIP-1271 for verification.

The 1st point is the most common mistake: if the nonce is generated by the client, or if the server does not record "used nonces," replay protection is effectively non-existent.

3.3 EIP-155: Signing the Chain ID into the Transaction

Before EIP-155, the content of a transaction signature was (nonce, gasPrice, gasLimit, to, value, data), which contained no information regarding "which chain this is." After EIP-155, it became:

$$\mathrm{Sign}\big(\mathrm{RLP}(\text{nonce}, \text{gasPrice}, \text{gasLimit}, \text{to}, \text{value}, \text{data}, \textbf{chainId}, 0, 0)\big),$$

The $v$ value in the signature also encodes the chainId. Now, mainstream wallets strictly enforce EIP-155, and EIP-712 structured signatures also have their own domain (including chainId and contract address); see "Blind Signing vs. What You See Is What You Sign."

3.4 Only sign what you can understand

Another prerequisite for secure signature login is that the wallet can parse and display the message. If a website asks you to sign a string of incomprehensible hexadecimal (signing a raw hash eth_sign), it might not be a login message at all, but rather a transaction hash. Therefore, a correct implementation requires: login should only use personal_sign to sign readable text, and never use eth_sign.

Summary