hc-httpclient-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kevin Crosbie <kcros...@ravenpack.com>
Subject Re: Repeated Proxy-Authorization Challenges
Date Wed, 14 Nov 2007 14:56:37 GMT
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.

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:

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;"

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

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.
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

View raw message