Nonce Challenge

Overview

A server begins the process by generating a cryptographically strong nonce and associating it with a session or account request. The user’s wallet signs a structured message containing that nonce. The server verifies the signature and checks that the nonce is still valid and unused.

The nonce proves freshness, not identity by itself. The signature proves control of the private key for the signing address. Linking that address to a real person or customer requires separate evidence.

Secure challenges include domain and purpose information so a signature requested by one application cannot be replayed at another. They should have short expiration, one-time consumption, and server-side storage or a verifiable signed state. Predictable or reusable nonces weaken protection.

User interfaces should display meaningful text rather than asking users to sign opaque data. A malicious website can trick users into signing messages with broader permissions than simple login.

Nonce challenges are also used in API authentication, device enrollment, and proof-of-reserves workflows. The same principle applies: the verifier supplies fresh data so the response demonstrates current control rather than replaying a previously valid proof.

The challenge should be generated with a cryptographically secure random source and enough entropy to prevent guessing. Storing only a predictable counter or timestamp can weaken protection if other context is missing. Verification endpoints should rate-limit failed attempts and mark the nonce consumed atomically with successful authentication. This prevents two simultaneous requests from reusing the same signed response.

Servers should reject challenges created for another session, domain, or requested action.