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