We experience the same problem, on an i386 architecture.  The authentication
module is completely unusable in the present state.

As an additional comment:
passwords encripted with "crypt" (e.g. with htpasswd -d) actually work,
with the caveat that passwords longer than 8 characters are *not*
truncated and will always fail (even if the first 8 characters are
correct).  This is wrong in my opinion:

$ /usr/lib/squid/basic_ncsa_auth /etc/squid/passwd.conf 
user1 mypwd
OK 
user2 12345678
OK 
user2 123456789
ERR Password too long. Only 8 characters accepted.
user3 xyz
Segmentation fault
$

Here user1 and user2 have passwords crypted with "crypt", user3 has
an md5-encrypted password (like $apr1$...)

After some investigation I found the culprit... It seems that the
crypt library function causes a segfault when the encrypted password
is an $apr1$... type of md5 (like the one obtained using htpasswd.

A workaround consists to check for the first character of the
encripted password and call crypt only if it is not '$' (in function
basic_ncsa_auth.cc).

If needed I can provide a replacement rpm (with no guarantee!)

actually, crypt is not at fault.  However it returns NULL if its
second argument (salt) is invalid, and in particular this is the
case if the first or second character of "salt" is '$'.

It is the "strcmp" function that segfaults when its second
argument is NULL

I am unable to reproduce described behaviour. Could you please provide an example of passwd.conf entry responsible for segmentation fault?

Here it is:
test:$apr1$pWQO4bT3$OA8SrMW8vVsqXeug8CoPL0

as obtained with
$ htpasswd -nm test
New password: test
Re-type new password: test
test:$apr1$pWQO4bT3$OA8SrMW8vVsqXeug8CoPL

or any password *not* in the old 'crypt'
like: test:4GLXAEjzRT/4w

Authentication with the proxy is refused for user "test", in particular
we have:

$ /usr/lib/squid/basic_ncsa_auth /tmp/passwd.conf 
test test
Segmentation fault
$

========================================================================
We have the following entries in squid.conf:

auth_param basic program /usr/lib/squid/basic_ncsa_auth /etc/squid/passwd.conf
auth_param basic children 5
auth_param basic realm Squid proxy- Dipartimento...
auth_param basic credentialsttl 4 hours
auth_param basic casesensitive off
========================================================================

Just to go straight to the point, here is my proposed patch.  Please note that it also removes
an annoying problem (a bug itself in my opinion) when using DES passwords longer than 8 chars,
however the real problem here is that 'crypt' *could* return a NULL pointer
=========================================================================================================
# cat squid-3.2.5-crypt.patch 
--- squid-3.2.5/helpers/basic_auth/NCSA/basic_ncsa_auth.cc.md5  2012-12-10 10:53:26.000000000 +0100
+++ squid-3.2.5/helpers/basic_auth/NCSA/basic_ncsa_auth.cc      2013-02-20 16:51:22.753605034 +0100
@@ -114,6 +114,7 @@ main(int argc, char **argv)
     time_t change_time = -1;
     char buf[HELPER_INPUT_BUFFER];
     char *user, *passwd, *p;
+    char *crypted;
     user_data *u;
     setbuf(stdout, NULL);
     if (argc != 2) {
@@ -147,12 +148,9 @@ main(int argc, char **argv)
         if (u == NULL) {
             SEND_ERR("No such user");
 #if HAVE_CRYPT
-        } else if (strlen(passwd) <= 8 && strcmp(u->passwd, (char *) crypt(passwd, u->passwd)) == 0) {
+        } else if ( (crypted = crypt(passwd, u->passwd)) && strcmp(u->passwd, crypted) == 0) {
             // Bug 3107: crypt() DES functionality silently truncates long passwords.
             SEND_OK("");
-        } else if (strlen(passwd) > 8 && strcmp(u->passwd, (char *) crypt(passwd, u->passwd)) == 0) {
-            // Bug 3107: crypt() DES functionality silently truncates long passwords.
-            SEND_ERR("Password too long. Only 8 characters accepted.");
 #endif
         } else if (strcmp(u->passwd, (char *) crypt_md5(passwd, u->passwd)) == 0) {
             SEND_OK("");
=========================================================================================================

*** Bug 896374 has been marked as a duplicate of this bug. ***

I can confirm crashing on F18 ~> assigned.

Thank you for your patch, but removal of strlen check actually reverts upstream fix for 3107. Therefore, I will update squid in a way preserving strlen check of passwd. 

In the case that you would like to change passwd handling behaviour, please fill a bugreport in upstream bugzilla.

(In reply to comment #8)
> Thank you for your patch, but removal of strlen check actually reverts
> upstream fix for 3107. Therefore, I will update squid in a way preserving
> strlen check of passwd.

Yes sure. The bugfix for 3107 is not actually involved in the segfault
issue.

> In the case that you would like to change passwd handling behaviour, please
> fill a bugreport in upstream bugzilla.

How can I do that? Is there a website that I can use?

Upstream bugzilla is available at bugs.squid-cache.org

squid-3.2.8-2.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/squid-3.2.8-2.fc18

*** Bug 918529 has been marked as a duplicate of this bug. ***

I have hust upgraded to squid-3.2.8-2.fc18. It's works! Thank you.

Package squid-3.2.8-2.fc18:
* should fix your issue,
* was pushed to the Fedora 18 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing squid-3.2.8-2.fc18'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-3613/squid-3.2.8-2.fc18
then log in and leave karma (feedback).

Works for me... There still is a problem with users having DES password longer than 8 characters.  We have some, and I have no simple way to contact them and
tell them that they *must* enter only the first 8 characters.  Put this way
patch 3017 of squid bugzilla is hardly a bugfix :-)

I reported this upstream, but there is no reply yet...

squid-3.2.8-2.fc18 has been pushed to the Fedora 18 stable repository.  If problems still persist, please make note of it in this bug report.