]> git.ipfire.org Git - thirdparty/squid.git/commit
digest_ldap_auth: Add -r option to clamp the realm to a fixed value
authorEmmanuel Fuste <emmanuel.fuste@thalesgroup.com>
Wed, 8 Feb 2017 19:12:00 +0000 (08:12 +1300)
committerAmos Jeffries <squid3@treenet.co.nz>
Wed, 8 Feb 2017 19:12:00 +0000 (08:12 +1300)
commit46e791c629e44630fe6e1df32bb0d73f10b1299d
tree0442222090c4a87b5a90ddeae373b2f709af7d68
parent25660541d392ebd334b6d34c23f0f015d4362491
digest_ldap_auth: Add -r option to clamp the realm to a fixed value

Some historic Digest Auth implementations do not include the realm in the
digest password attribute. The password is effectively stored as "HA1"
instead of "REALM:HA1".

The realm cannot simply be ignored due to:
 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.

To resolve all these problems allow the -l parameter to accept an empty
string ('-l "" ') when the -r option provides a fixed realm.

Also, fix several typos in the help text.
src/auth/digest/LDAP/ldap_backend.cc