I've committed a fix to this and to
the code that checks if a nonce is expired (Helper.cxx). It should be working
with unsigned int's correctly now.
Note: We may want to consider using 64bit
timestamps in a nonce, so that we will not have the year 2036 issue with the
32bit timestamp we currently use.
Thanks Alex!
Scott
From: Cullen Jennings
[mailto:fluffy@xxxxxxxxx]
Sent: Monday, April 25, 2005 6:55
PM
To: alt;
resiprocate-devel@xxxxxxxxxxxxxxxxxxx
Subject: Re: [reSIProcate]
Negative nonce value
Yah, I think we need to rethink how we generate the nonce - having them be this
predictable might have other issues too.
On 4/25/05 10:15 AM, "alt" <alt@xxxxxxxxx> wrote:
Hi All
During testing authentication I have found problem with "nonce"
value within challenge response returned by ServerAuthManager
The problem is:
We use next code to generate "nonce":
---8<---------------------------------------------------------------------------------
Helper::makeProxyChallenge(const
SipMessage& request, const
Data& realm, bool
useAuth, bool stale)
{
Auth auth;
auth.scheme() = "Digest";
Data
timestamp((int)(Timer::getTimeMs()/1000));
auth.param(p_nonce) = makeNonce(request, timestamp);
...
---8<---------------------------------------------------------------------------------
because of timestamp is too big (in my case) when casted to int I get negative
value.
But later we check is the first char of "nonce" digit.
Using next code solves the problem:
Data timestamp((unsigned
int)(Timer::getTimeMs()/1000));
But it's not only place when we use this construction (cast to int).
Must we change the way how we generate "now" nonce (in second)
everywhere?
Regards,
Alex
_______________________________________________
resiprocate-devel mailing list
resiprocate-devel@xxxxxxxxxxxxxxxxxxx
https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel