hc-httpclient-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oleg Kalnichevski <ol...@apache.org>
Subject Re: Repeated Proxy-Authorization Challenges
Date Wed, 14 Nov 2007 15:18:56 GMT

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


Mime
View raw message