On Wed, 2007-11-14 at 15:56 +0100, Kevin Crosbie wrote:
> Oleg Kalnichevski wrote:
> > There is a trade-off between security and performance. The whole of
> > point of generating new nonce values is to make Digest authentication
> > less prone to brute-force attacks. The less frequently nonce changes,
> > the more likely is the change the authentication can be brute-forced.
> > Preemptive authentication simply defeats the purpose of the Digest
> > authentication scheme.
> >
> > In general any kind of preemptive authentication is a security risk.
> >
> >
> Oleg,
>
> Thanks for the response.
>
> The security considerations are quite well outlined in rfc2617, however
> I don't think that the generation of a new nonce value makes it less
> prone to other attacks, for instance, gathering lots of data for a
> chosen plaintext attack. Anyway, far be it from me to comment on
> security protocol, at best I can quote "This scheme is not considered to
> be a secure method of user authentication" from the rfc (See:
> http://www.ietf.org/rfc/rfc2617.txt).
>
As far as I understand this statement refers to the Basic scheme.
The Digest scheme may not be as secure as Kerberos or NTLM but the point
I am trying to make is that reducing the frequency at which the server
updates the nonce value makes Digest authentication _less_ secure.
> One point I would like to point out from the rfc, is in section 3.3
> "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;"
>
I am not saying it is not feasible. I am merely questioning the
soundness of this concept.
> Here it describes how a server may accept the same nonce, if the client
> tries it, or may tell the client to retry. Some servers even send a
> new nonce using the AuthorizationInfo header so that the client can be
> somewhat preemptive. The behaviour should be left up to the server to
> decide.
>
> In any case, from what I've seen in the source and from the comments
> I've received from both you and Roland, it seems that this is not a part
> of the HttpClient.
There is a feature request for that, which we will look at in the course
of 4.0 development:
https://issues.apache.org/jira/browse/HTTPCLIENT-424
Cheers
Oleg
> I am quite content to live with the repeated challenges, from a user
> perspective it is completely transparent.
>
> Best Regards,
>
> Kevin Crosbie
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: httpclient-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-user-help@jakarta.apache.org
|