RE: [squid-users] Digest authentication helper question

Ah, I didn't realize the protocol combined the realm and password in the hashed value sent from client->server, thought those were separate.
Makes sense now. Thanks very much for the fantastically detailed explanation.

-----Original Message-----
From: Henrik Nordström [mailto:henrik_at_henriknordstrom.net]
Sent: Saturday, June 05, 2010 3:01 PM
To: David Parks
Cc: squid-users_at_squid-cache.org
Subject: 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 - 22:24:23 MDT