When implementing a HTTP Digest server, there's the issue of nonces.
Server nonces (as opposed to client nonces)
- must be issued by the server
- may be re-used by clients as long as the server allows it
- knows nothing about what user will use the nonce later
A naïve implementation is to remember all issued nonces in memory, but this introduces state: Either a client needs to talk to the same server, or the servers need to share the list of valid nonces, which becomes a scalability issue.
My question is: Is it possible to provide secure and stateless nonces? I believe so, and would like it to be (in)validated:
Make the nonce a cryptographically signed message from the server:
- an expiry timestamp (e.g. 86400 seconds in the future)
- an a random number (maybe?)
- a cryptographic signature (sha or hmac perhaps?)
This could all be bundled together in the nonce which is provided in the 401 Www-Authenticate header. When any server sees this, they can verify the message integrity (by recalculating the signature). Then the timestamp can be checked, and if so then the nonce is good.
- Is this technique described elsewhere?
- Does this way of providing nonces defeat the purpose of nonces?
- Is there any other way of providing stateless HTTP Digest authentication?