You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@httpd.apache.org by Allasso Travesser <al...@gmail.com> on 2013/12/22 15:07:24 UTC
[users@httpd] Does mod_auth_digest not determine session expiration?
Hello,
I have been studying mod_auth_digest to determine how it knows when when a browser has ended its session, thinking it sends metadata to tell the browser to prompt the user again for login/password at the beginning of a new session. I was interested in the behavior which I observed for different browsers where after shutdown and restart, user would be prompted to provide login info again. Even on some browsers which save sessions after shutdown e.g. Firefox and Safari would still prompt for login.
What I seem to have found is that the only metadata the server sends in regard to needing authorization is a 401, and thus have concluded it is the browser which determines the behavior of requiring re-entering login info. This seemed to be confirmed when I tried shutdown/restart on Chrome, and it did not require re-entering login info.
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?
Thanks,
Allasso
Re: [users@httpd] Does mod_auth_digest not determine session expiration?
Posted by Ben Reser <be...@reser.org>.
On 12/22/13, 3:13 PM, Allasso Travesser wrote:
> Thank you, Ben, very informative. So I get from this that unmodified, mod_auth_digest behaves as I said, though it could be modified to force the browser to do a prompt.
Yes, sorry if I wasn't very clear about that.
> I note that in any case though, the module has no knowledge of what the user is doing with the browser, such as shut-down/restart, and there is no standard which requires the browser to send such information to the server.
Correct. As far as I know the RFC I linked to is the only RFC that talks about
Digest authentication.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd] Does mod_auth_digest not determine session expiration?
Posted by Allasso Travesser <al...@gmail.com>.
Thank you, Ben, very informative. So I get from this that unmodified, mod_auth_digest behaves as I said, though it could be modified to force the browser to do a prompt.
I note that in any case though, the module has no knowledge of what the user is doing with the browser, such as shut-down/restart, and there is no standard which requires the browser to send such information to the server.
On Dec 22, 2013, at 3:56 PM, Ben Reser <be...@reser.org> wrote:
> 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],
>
> stale
> 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] http://www.ietf.org/rfc/rfc2617.txt (section 3.3)
> [2] http://www.ietf.org/rfc/rfc2617.txt (section 3.2.1)
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
> For additional commands, e-mail: users-help@httpd.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd] Does mod_auth_digest not determine session expiration?
Posted by Ben Reser <be...@reser.org>.
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],
stale
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] http://www.ietf.org/rfc/rfc2617.txt (section 3.3)
[2] http://www.ietf.org/rfc/rfc2617.txt (section 3.2.1)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org