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 _______________________________________________ squid-dev mailing list [email protected] http://lists.squid-cache.org/listinfo/squid-dev
