Wallet Login Nonces and Replay Protection
Protect wallet-signature login with single-use challenges, domain binding and expiry, without treating a reusable signed message as a permanent session.
Overview
When translating these concepts into an integration, keep the scope described by the wallet history api with the result. The examples in wallet transaction history and smart contract event logs show how the same distinction affects neighbouring data questions.
A wallet signature can prove control under a specific verification scheme. Authentication also needs a server-side challenge lifecycle so a captured valid message cannot simply be replayed to create new sessions.
Bind the challenge to context
Generate an unpredictable challenge and associate it with the intended domain, URI, chain context and expiry. Validate the complete message under the chosen standard, not only the recovered address. Consume the challenge atomically after successful verification. A timestamp alone is not an adequate substitute for a single-use nonce.
Worked example: two simultaneous replays
Two requests present the same valid signed challenge. If each checks unused status before either writes consumed status, both can create sessions. An atomic consume operation makes only one eligible. The second request receives a defined replay failure without revealing secret session material.
Test message and lifecycle failures
Include wrong domains, expired challenges, changed chain context and a challenge generated for another session. Use the appropriate contract-wallet verification path when supported. Keep the resulting web session separate from the signature evidence and apply ordinary session expiry and revocation rules. Do not ask users to sign a transaction for a simple read-only login.
A practical acceptance test
Race two verification requests for the same valid challenge. Assert a single atomic consumption and no duplicate session issuance. Add wrong-domain and expired challenges, then repeat with a contract-wallet verifier where supported. Safe errors should describe the failed condition without exposing session tokens, reusable signatures or another account’s challenge state.
Questions about the topic
Frequently asked questions
Is a signature alone a complete login protocol?
No. Challenge context, replay handling and session controls are also required.
Can a nonce be reused after a failed session response?
Only under a deliberately designed recovery contract; do not blindly reaccept consumed challenges.
Standards & technical documentation
