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?
On Tuesday 17 November 2009, Alex Hermann wrote:
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?
Also the nonce reusage check is in post_auth. Why not check it before DB access is done?
Here's the patch by the way.
Alex,
On Tue, Nov 17, 2009 at 4:13 PM, Alex Hermann alex@speakup.nl wrote:
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 cached 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.
-- Jan
On Tue, Nov 17, 2009 at 5:00 PM, Jan Janak jan@ryngle.com wrote:
Alex,
On Tue, Nov 17, 2009 at 4:13 PM, Alex Hermann alex@speakup.nl wrote:
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
Errata: the server sends back stale=tru in digest challenge...
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 cached 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.
-- Jan
-
Alex Hermann -
Jan Janak