Hi Amos,
Thanks for the comments!
On 2016-11-12 07:48, Amos Jeffries wrote:
I can't reproduce the problem using Squid 3.5.22. I used following
method to verify the case:
Unfortunately your test uses the 'openssl' tool below instead of
htpasswd to create the password file. There are some big differences in
security algorithms each uses to reate the password file.
My primary task was to confirm that 20k passwords DB file is not an
issue for Squid.
I used htpasswd-compatible MD5 algorighm (-apr1), it is equivalent to
'htpasswd -m'.
The openssl key -crypt is equivalent to 'htpasswd -d'.
You are right, I missed the specified '-d' flag.
2. Create ncsa passwords db for 20k users.
# for i in {1..20000}; do echo "user${i}:$(openssl passwd -apr1
pass${i})" >> /usr/local/squid35/etc/passwd; done
This test *will* fail when "htpasswd -db" is used to generate the
password file from those password strings. Notice that the test 'i'
values of 10000+ create passwords like "pass10000" which are 9
characters long.
The htpasswd -d uses DES encryption which has an 8 character limit on
password length. It will *silently* truncate the password to the first
8
characters.
Recent basic_ncsa_auth helper versions will detect and reject
authentication using DES algorithm when password is longer than 8
characters.
Thanks. I found the relevant commit 11632 [1] and the associated bug
report 3107 [2] discussion.
I have a question, maybe there should be an optional argument which
could be used to permit old behavior? For example, Apache HTTP server
still permits passwords longer then 8 characters.
[1] http://bazaar.launchpad.net/~squid/squid/5/revision/11632
[2] http://bugs.squid-cache.org/show_bug.cgi?id=3107
Garri
_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
http://lists.squid-cache.org/listinfo/squid-users
