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

[Amos Jeffries]

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.

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.

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?

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.


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.

Amos