9

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:

  1. an expiry timestamp (e.g. 86400 seconds in the future)
  2. an a random number (maybe?)
  3. 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?
mogsie
  • 255
  • 2
  • 6

1 Answers1

9

If the server is stateless, whatever the clients sends to "get authenticated" can be replayed. An attacker only has to eavesdrop on a request by a client, and then can send his own request with the relevant header simply copied. An expiry date prevents the attacker from doing that indefinitely, but even if the attacker can wreck havoc within your server only during one day, this is still unsatisfactory. Possibility of replay attacks is consubstantial to statelessness; it is unavoidable.

And HTTP Digest is not a great protocol anyway. HTTP Digest ensures a security service only in a model where attackers can potentially spy on exchanged data, but not alter it; this is not a very realistic model. In practice, you need something more thorough, like SSL, at which point you can send the password as is (HTTP Basic) and forget about HTTP Digest.

Thomas Pornin
  • 320,799
  • 57
  • 780
  • 949
  • +1 for the "server is stateless" being directly counter to "replayed". Obvious, in fact. You could have once-only nonces (although this again introduces state) e.g. for POST operations, or perhaps even for certain particularly unsafe requests. You could also have the nonces' validity set to 5 minutes; user agents transparently re-encrypt when asked to. The biggest attack vector IMHO is still spying (wi-fi and promiscuous ethernet), where changing data is a lot harder. I don't care about MITM attacks, otherwise I wouldn't be using Digest. – mogsie Jan 28 '12 at 08:17
  • FWIW, this didn't really answer my questions... – mogsie Jan 28 '12 at 20:16
  • HTTP Digest authentication includes nonce counters which mitigate replay attacks. Squid even has "strict" digest mode in which it enforces the correct sequence of nonce counters and in those cases forces a new nonce on the client. The most recently used nonce counter then becomes the only "state" that can't solely be put on the client (in order to avoid replay attacks). But I understand your now :-) – mogsie May 23 '12 at 20:13
  • "HTTP Digest ensures a security service only in a model where attackers can potentially spy on exchanged data, but not alter it" some client support rfc2617 auth-int mode which authenticates the message body "HTTP Digest authentication includes nonce counters which mitigate replay attacks" only if you have state, the stateless model the OP describes still suffers from the ability to replay full request bodies, but using auth-int mode can at least keep them from using one authenticated response to authenticate a *different* request – david king Sep 28 '14 at 20:16