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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
