Official MASTR logo MASTR
Menu
Contents
← Wiki home

Technical reference

Sign-In with Ethereum: what a login signature actually opens

Read the domain, the challenge and the session before treating a signature as a harmless login.

Source-based reference · Updated 9 October 2026

Research articles and reference entries are published in English. Navigation is available in seven languages.

In this article
  1. Read the request, not the button
  2. A session is a separate permission boundary
  3. A practical review
  4. Check your understanding
  5. Sources

Read the request, not the button

A button labelled Connect tells you little about the next wallet prompt. ERC-4361, usually called Sign-In with Ethereum or SIWE, defines an offchain authentication message. A conforming message identifies the requesting domain, wallet address, URI, chain, nonce and issue time. It can also include an expiry. Read those fields before signing.

The service checks the message and signature before establishing a session. A nonce is the challenge that helps stop an old response being accepted as a fresh login. Recovering the expected address alone is insufficient: the server must also check the expected message fields. The wallet has its own responsibility to check the requesting origin.

A session is a separate permission boundary

SIWE authentication does not itself execute a blockchain transfer. It also does not define every action the resulting website session may perform. A genuine login and a token-spending permit are different requests. A familiar website or a zero-gas prompt is no substitute for reading the actual payload.

Contract wallets add another check. ERC-1271 lets the account contract decide whether a signature is acceptable. The answer can depend on its signer set or other state. A verifier that only recovers one ordinary private-key address can reject a legitimate smart wallet or apply the wrong validation model.

A practical review

For an integration you control, try a valid login, then repeat the consumed challenge, change the domain and submit an expired message. Record which check rejected each request. Also test a supported contract wallet. These are separate cases; one successful login proves none of the others.

For a user, the useful question is precise: which site gets a session for which wallet, and what happens after sign-in? If the prompt instead names a spender, spending amount or contract action, stop treating it as an ordinary login.

Sources

Sources checked 9 October 2026

Related reading