RE: [squid-users] Re: ntlm won't prompt

On Fri, 2003-07-11 at 22:39, Adam Aube wrote:

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

K.

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

Exactly. There's a thing with stored secrets - 'cleartext equivalent'.
The NT SAM contains cleartext equivalent passwords, which it uses to
authenticate logins. The point being that compromise of cleartext
equivalent data is equivalent to compromise of the cleartext password -
and that digest is no worse than any other shared secret system in that
respect.

> This currently presents integration issues - vendors would need to
> use some sort of standard for the realm, then precompute and store the HHA1.

Uhm, worse than that: Either the directory service has the cleartext
(but not squid), or the realm is fixed and cannot change. This is
because if the realm changes, all HHA1's need to be regenerated from the
cleartext.

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

We support nonces, but not client nonces. md5-sess requires client nonce
support.

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

NT Provides Digest for IIS, but under some constraints:
* You MUST have an AD Domain
* You MUST turn on 'store passwords with reversible encryption' in the
AD policies.
So yes - you are right that *some agent* needs the cleartext. I've been
looking at the risks of exposure, not at whether the cleartext is needed
/somewhere/.

> What about using SSL over the client <-> proxy connection? You would get the
> easy
> integration of basic auth without its insecurity.

To enlarge on my other message, this is actually less secure in a funny
way.

lets compare a hypothetical digest SSO, and a hypothetical basic/ssl SSO
:

you need three components:
Directory
squid
browser

for digest:
squid creates a nonce, challenges the client.
the client gets the challenge, creates it's own nonce, hands both to the
directory service over its *already existing* secured link, and recieves
back a one-time HHA1 - specific to the two nonces. the client then sends
the calculated digest response using the HHA1.
squid recieves the response, with the new client nonce. squid then
requests a HHA1 to match (user, realm, squid-nonce, client-nonce) from
its connection to the directory service. squid then is able to validate
the response.

note that at -no- point does the cleartext OR a cleartext equivalent
leave the directory service.

for basic/ssl:
client initiates ssl to squid
squid challenges the client to login
the client sends all the headers except the login details, then asks the
directory service to send the login header over the FD, then resumes
control of the FD and sends any remaining data.
squid recieves the cleartext username and password, hands them off to
the directory service for validation.

note that because the directory service has to send cleartext down the
FD, it's possible (i.e. by passing a pipe to the directory service) to
get the users cleartext password.

So: while basic/ssl will prevent eavesdropping on the users password,
it's not substantively more secure -as a whole-.
Rob

-- 
GPG key available at: <http://members.aardvark.net.au/lifeless/keys.txt>.