Re: [squid-users] Digest authentication helper question

lör 2010-06-05 klockan 09:07 -0600 skrev David Parks:
> Hi, the digest authentication helper protocol requires that the helper
> return the encrypted digest authentication hash given the username and
> realm.

Yes..
 
> The problem is, if I have 2 different realms which authenticate against the
> same user credentials, if I store the credentials in a one-way encrypted
> format (obviously preferable) I have to store them with the realm included
> in the encryption, because I have to pass this back to squid via the helper.
> In this case I would have to store a password for each realm, and could
> never change the realm. Or I'm going to have to store the passwords
> unencrypted so I can encrypt them with the realm in the helper.

Yes..
 
> Why not just use the same OK/ERR scheme that basic auth uses? This way the
> helper can do the validation its own way without tying our hands when it
> comes to situations like this?

You would still have the limitations above as those are from the
authentication protocol as such, and not really related to Squid. Digest
auth exchanges crypt§ographic hashes based on the password, and the
plain text password is never known to the proxy.

The digest auth data given to Squid by the browser is:

    digest-request = MD5(MD5(user ":" realm ":" password) ":" nonce ":"
nc ":" cnonce ":" qop ":" MD5(method ":" uri))

which is sent as a sequende of 32 HEX digits representing 16
octets/bytes of "random" data.

The proxy verifies digest authentication by performing the same
calculation outlined above based on the digest request parameters and
verifies that it ends up with the same unique "random" data that the
client sent.

The per user unique shared secret component in that calculation is

   MD5(user ":" realm ":" password)

the rest is dynamic per request parameters set by the digest exchange
between browser & server(squid).

This shared secret is "the users password" as far as digest auth is
concerned, salted with the user & realm to guarantee uniqueness and
block reuse of the same secret for other services should it ever leak
from your auth backend somehow. And this is what Squid asks digest
helpers to return to enable Squid to perform the fine details of the
digest auth scheme calculcations.

The other option (not supported by Squid) would be to use the helper in
ways similar to what is done for the NTLM scheme and that's to offload
the whole auth processing to the helper with the proxy just acting as a
relay, and maybe MD5-sess offload from the helper back into the proxy to
avoid needing to call the auth helper on each and every request. (note:
MD5-sess is not supported by any browser from what I know, and broken in
many which try..)

Regards
Henrik
Received on Sat Jun 05 2010 - 21:01:00 MDT