17 Nov
2009
17 Nov
'09
9:42 p.m.
Jan,
On Tuesday 17 November 2009, you wrote:
On Tue, Nov 17, 2009 at 4:13 PM, Alex Hermann
<alex(a)speakup.nl> wrote:
The server can just as well generate a stale=true response immediately,
independent of the credentials check. If later on a non-expired nonce
arrives, it can do the credentials check and send a response without
stale=true if necessary.
Hello,
Why is the nonce expiry checked in post_auth instead of pre_auth? Now the
expiry is checked after the username/password is checked against the DB.
That seems a bit odd.
I moved the check to check_nonce (which is called from pre_auth) and it
seems to work fine. Did I miss something? Security issue?
There are two major reasons for this:
The server sends back stale=true in digest credentials if the nonce
has expired, but only if the credentials are otherwise valid (i.e. the
username and the password are correct). The parameter stale=true
indicates to the user agent that there is no need to ask the user for
username and password again, it can just generate a new authorization
header with ca> ched username and password and a new nonce string from
the server. The second reason is that we need to accept
credentials with old nonce
string for ACK and CANCEL requests. Those two requests cannot be
challenged (There is no reply for ACK and CANCEL must have the same
CSeq as the request being canceled), thus we cannot ask the user agent
to resubmit them again with a new nonce.
This reason is invalid because of the
following existing code in pre_auth:
if ((_m->REQ_METHOD == METHOD_ACK) || (_m->REQ_METHOD == METHOD_CANCEL))
return AUTHORIZED;
--
Met vriendelijke groet,
Alex Hermann
SpeakUp BV
T: 088-SPEAKUP (088-7732587)
F: 088-7732588