httpd-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ben Reser <>
Subject Re: [users@httpd] Does mod_auth_digest not determine session expiration?
Date Sun, 22 Dec 2013 22:56:59 GMT
On 12/22/13 6:07 AM, Allasso Travesser wrote:
> So I believe that mod_auth_digest has no and uses no mechanism for tracking
> sessions, and always operates in a stateless context.  In essence, for each
> request it checks the request header for proper login metadata, and if and only
> if it qualifies does it allow access, otherwise, it sends a 401.  The policy on
> prompting and gathering of login info from the user is entirely up to the browser.
> Does this sound correct?

Yes and no.  mod_auth_digest doesn't provide a way to configure this, though it
probably could.

You can specify the lifetime for the nonce with AuthDigestNonceLifetime.  Which
can trigger the client side to need to produce a new request which includes an
Authorization header that uses a new nonce.

The RFC says [1]:

  The authentication session lasts until the client receives another
  WWW-Authenticate challenge from any server in the protection space. A
  client should remember the username, password, nonce, nonce count and
  opaque values associated with an authentication session to use to
  construct the Authorization header in future requests within that
  protection space. The Authorization header may be included
  preemptively; doing so improves server efficiency and avoids extra
  round trips for authentication challenges. The server may choose to
  accept the old Authorization header information, even though the
  nonce value included might not be fresh. Alternatively, the server
  may return a 401 response with a new nonce value, causing the client
  to retry the request; by specifying stale=TRUE with this response,
  the server tells the client to retry with the new nonce, but without
  prompting for a new username and password.

and [2],

     A flag, indicating that the previous request from the client was
     rejected because the nonce value was stale. If stale is TRUE
     (case-insensitive), the client may wish to simply retry the request
     with a new encrypted response, without reprompting the user for a
     new username and password. The server should only set stale to TRUE
     if it receives a request for which the nonce is invalid but with a
     valid digest for that nonce (indicating that the client knows the
     correct username/password). If stale is FALSE, or anything other
     than TRUE, or the stale directive is not present, the username
     and/or password are invalid, and new values must be obtained.

So it should be possible to change the module to force reprompting of the
password on the client by simply omitting the stale=true from the
WWW-Authenticate header.  That could be done by adding a new timeout that once
the nonce age passes it doesn't send stale=true or by a configuration flag that
specifies that the sale=true isn't sent when the nonce lifetime has expired.

This all assumes that the clients actually follow the RFC (and interpret the
same way I am) in this regard and I haven't bothered to test that.

The RFC ultimately says nothing about how long a client should cache the
credentials.  It implies that the client should prompt the user for credentials
if stale isn't true, but given that browsers have password caching, I'd suspect
that even the above may not be reliable since some browsers may simply try
their cached credentials first.

[1] (section 3.3)
[2] (section 3.2.1)

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message