[squid-dev] [PATCH] Digest Auth support for LDAP HA1 attribute without realm

[FUSTE Emmanuel]

Le 29/01/2017 à 14:33, Amos Jeffries a écrit :
> On 21/01/2017 2:05 a.m., FUSTE Emmanuel wrote:
>> Hello,
>>
>> We have to support many historic digest auth implementation for which
>> the realm is not included in the digest password attribute:
>> The password is effectively stored as "HA1" instead of "REALM:HA1".
>> I would like to kill our own homegrown helpers and use the Squid
>> provided one.
>>
>>    Is something like the attached patch is acceptable/could be included
>> in a future Squid release ?
>>
>> Best regards,
>> Emmanuel.
>> --
>
> Sorry it has taken me so long to respond on this. I wanted to verify the
> importance of realm in the H(A1) digest. Why it was marked as REQUIRED
> to begin with.
No, thank you to have taken the time.
> Sadly I have to report my suspicion was correct and I vote -1 on this in
> its current form. BUT I can think of two ways to get around it, see end
> of this mail.
>
>
> The problems are that;
>   1) the realm is both the salting value used within the hash and the
> scope limitation on what inputs from HTTP are used to compare against
> the A1, and
>   2) Squid does not itself verify the realm received was the one offered
> and leaves the comparison to the backend system. There is some
> possibility the authentication system is using multiple security realms
> and Squids realm string is just an offer.
>
>
> Not having realm tied to the credentials in the backend storage leaves
> this particular helper with no other option but to trust the realm sent
> (probably) over clear-text by any client/attacker actually matches the
> salting. That allows remote senders to manipulate the realm string they
> send to perform a collision attack against the stored password.
>   They no longer have to find and prove knowledge of the password. But
> just find a collision for its hash vs arbitrary realm strings.
Ok point taken.

> Old Digest systems are not the safest things to begin with. They also
> tend to use MD5 hashing which was the only one available for many years
> and relatively easy to find collisions for.
>
>
>
> Workaround #1:
>
> Is there just one (or a few) realm that all your stored passwords use?
Yes only one, as we lost the ability to iterate over multi-valued entry 
using the realm as a key.
> I think we can accept the absence of realm per-password if there were a
> global realm to check against instead. A command line option could be
> added to pass an explicit realm (or multiple?) which the helper can use
> to reject the possible attacks.
Ok, so a rework of the patch with a mandatory command line option to 
specify the realm in case of null delimiter will be acceptable ?
I think that "an explicit realm" is sufficient. To have multiple realm, 
something like  realm:HA1 must already be in place or is really 
completely broken by design.
Mono "hard-coded in conf" realm is not flexible but not broken -> I know 
a lots of such setup. That is what I would like to address.
I don't know any real setup which need the "multiple possible implicit 
realm in conf" way
>
> Workaround #2:
>
> Emmanuel;  are you able to easily implement a LDAP field that adds a
> second 'realm:password' value to the LDAP for this helper to check for
> without changes?
>
> That is probably the best approach long-term. AFAIK realm:HA1 is a
> fairly standard format for modern Digest systems so it may be neeed
> anyway for other software than Squid.
Yes, this is the best approach, but I have no control on the downstream 
LDAPs. The problem is reported to the customer(s) but I could not 
"force" them to migrate quickly as we talk about big installations (8k 
to 80k users or more) with lots of specific in house applications using 
the same LDAP servers.

Emmanuel.