> Well, there's a little project then :}. In point of fact, in 3.0 squid > can read pre-digested passwords in the supplied helper.
Well, that's good news. > You completely misunderstand how digest auth works. See RFC 2617 for the > spec.. Based on the info you provide here, I think I did understand it - I just didn't know of any implementation that didn't require the cleartext password. > What is needed to verify the password is the HHA1 (see the spec), which > is MD5(user:realm:password) - possibly combined with one time nonces > from the client and the server (thats md5-sess, which we don't support > (yet)). That's the problem - it's not an MD5 of just the password. So either the HHA1 needs to be precomputed and stored, or the cleartext password must be known. This currently presents integration issues - vendors would need to use some sort of standard for the realm, then precompute and store the HHA1. BTW, if Squid doesn't support the use on nonces, why are there squid.conf parameters - such as nonce_max_duration and nonce_max_count - to regulate their use? > Once you have HHA1, then you can issue challenges and verify responses, > without knowledge of the password. Yes, however, how many vendors store the HHA1 in their password databases by default, and automatically recompute it at password change? The only current option is to maintain a separate database just for Squid. Both Basic and NTLM are currently easier to integrate (NTLM provided you use a Samba/Windows domain). What about using SSL over the client <-> proxy connection? You would get the easy integration of basic auth without its insecurity. Adam --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.237 / Virus Database: 115 - Release Date: 3/7/2001