Hello,
Le 30/01/2017 à 16:04, FUSTE Emmanuel a écrit :
> 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
>
New patch attached.
- Empty realm parameter is treated as no realm parameter supplied.
- realm parameter is mandatory if empty delimiter is supplied
- -f vs -F typo corrected in the help text
Tested in real conditions.
Emmanuel.
----
--- squid3-3.5.23/helpers/digest_auth/LDAP/ldap_backend.cc.manu 2017-01-18
15:41:31.021707038 +0100
+++ squid3-3.5.23/helpers/digest_auth/LDAP/ldap_backend.cc 2017-02-07
10:29:07.026005928 +0100
@@ -63,6 +63,7 @@
static const char *binddn = NULL;
static const char *bindpasswd = NULL;
static const char *delimiter = ":";
+static const char *frealm = "";
static int encrpass = 0;
static int searchscope = LDAP_SCOPE_SUBTREE;
static int persistent = 0;
@@ -267,7 +268,7 @@
}
value = values;
while (*value) {
- if (encrpass) {
+ if (encrpass && *delimiter ) {
const char *t = strtok(*value, delimiter);
if (t && strcmp(t, realm) == 0) {
password = strtok(NULL, delimiter);
@@ -451,6 +452,9 @@
case 'l':
delimiter = value;
break;
+ case 'r':
+ frealm = value;
+ break;
case 'b':
userbasedn = value;
break;
@@ -574,10 +578,11 @@
if (!ldapServer)
ldapServer = (char *) "localhost";
- if (!userbasedn || !passattr) {
- fprintf(stderr, "Usage: " PROGRAM_NAME " -b basedn -f filter [options]
ldap_server_name\n\n");
+ if (!userbasedn || !passattr || (!*delimiter && !*frealm)) {
+ fprintf(stderr, "Usage: " PROGRAM_NAME " -b basedn -F filter [options]
ldap_server_name\n\n");
fprintf(stderr, "\t-A password attribute(REQUIRED)\t\tUser attribute
that contains the password\n");
- fprintf(stderr, "\t-l password realm delimiter(REQUIRED)\tCharater(s)
that devides the password attribute\n\t\t\t\t\t\tin realm and password tokens,
default ':' realm:password\n");
+ fprintf(stderr, "\t-l password realm delimiter(REQUIRED)\tCharater(s)
that devides the password attribute\n\t\t\t\t\t\tin realm and password tokens,
default ':' realm:password, could be\n\t\t\t\t\t\tempty string if the password
is alone in the password attribute\n");
+ fprintf(stderr, "\t-r filtered realm\t\t\tonly honor Squid requests
for this realm. Mandatory if the password is alone in\n\t\t\t\t\t\tthe password
attribute, acting as the inplicit realm\n");
fprintf(stderr, "\t-b basedn (REQUIRED)\t\t\tbase dn under where to
search for users\n");
fprintf(stderr, "\t-e Encrypted passwords(REQUIRED)\tPassword are
stored encrypted using HHA1\n");
fprintf(stderr, "\t-F filter\t\t\t\tuser search filter pattern. %%s =
login\n");
@@ -646,7 +651,14 @@
{
char *password;
ldapconnect();
- password = getpassword(requestData->user, requestData->realm);
+ if (*frealm)
+ if (!*delimiter && strcmp(requestData->realm, frealm))
+ password = NULL;
+ else
+ password = getpassword(requestData->user, (char*)frealm);
+ else
+ password = getpassword(requestData->user, requestData->realm);
+
if (password != NULL) {
if (encrpass)
xstrncpy(requestData->HHA1, password, sizeof(requestData->HHA1));
@@ -660,4 +672,3 @@
}
}
-
_______________________________________________
squid-dev mailing list
squid-dev@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-dev
