Hey,
using webmin in a kvm vps just to manage squid users. it was working fine for years, after many OS dist-upgrades.
yesterday, a new squid user added from webmin module, couldn’t use squid at all. another new user added for test, same behavior. changing password on an existing user, the same. 407/authentication issues for those, on logs.
existing+unchanged users/passwords have no issues at all.
so after hours of searching, and even dist-upgrading OS to get newer squid v6, i think i got something. if password is changed/added from webmin module, it fails. (this is new, happening only during the last days(weeks perhaps? not sure when last succesful user was added…)
if i manually add/change squid user password using htpasswd, it works fine, no issues.
any ideas/hints why this happens?
squid.conf :
auth_param basic program /usr/lib/squid/basic_ncsa_auth /etc/squid/passwd
auth_param basic children 10
auth_param basic realm Squid proxy-caching web server
auth_param basic credentialsttl 2 hour
auth_param basic casesensitive off
The Webmin Squid module and htaccess-htpasswd modules haven’t changed in years, so I don’t think it can have anything to do with Webmin.
I don’t remember how passwords are handled in the Squid module, can you be specific about the workflow you use to change or add a password in the Webmin module? (Is it in the Squid module? There is also an htpasswd editor, so I want to be specific about what I’m looking at.)
there’s only webmin, running on a KVM VPS, a specific person logs in webmin as root, and goes into Squid module → Proxy Authentication. there, they modify/add proxy users. (~2400 users currently). so, webmin url for user changes/additions is :10000/squid/edit_nauth.cgi?xnavigation=1
maybe someone can try with a fully upgraded debian 12 system and squid module to see if it’s working ok for them? (add a user, try to login to proxy after. w/ basic auth)
we were using debian 12 when error occured. while trying to troubleshoot, i thought i’d give squid v6 a try… so i’ve dist-upgraded to trixie in order to test with newer versions of all packages. (= no luck)
haven’t reverted to debian 12, still using trixie on this machine. no issues so far, but apart from webmin + squid + apt-cacher-ng , there’s no other services running.
ok, i think i found out what’s happening. passwords longer than 8chars don’t work. any password <8chars is working fine, while longer ones fail. with longer passwords user has to use only first 8chars of the password in order to login. using full password will fail with auth error (407). that’s crypt limitation i think. (?)
running htpasswd , there is no crypt option at all. just md5, sha1, etc… all salted. and squid users created/modified with it can login normally, longer passwords work fine.
webmin squid module doesn’t add salt to passwords and has this 8char limit.
we probably noticed just now, because new (2025) users mostly use >8chars passwords…
btw, if i go to :10000/config.cgi?module=squid&_cscript=index.cgi&xnavigation=1
and change Encryption method for proxy passwords
to use other option “md5base64”, i can no longer view Proxy Authentication option in squid module. there’s just an “Error” with blank page.
miniserv.err :
/squid/edit_nauth.cgi : ?
Argument “” isn’t numeric in array element at /usr/share/webmin/squid/save_nuser.cgi line 25.
Argument “” isn’t numeric in array element at /usr/share/webmin/squid/save_nuser.cgi line 25.
Argument “” isn’t numeric in array element at /usr/share/webmin/squid/save_nuser.cgi line 25.
so, keeping this option “crypt”.
anyway, maybe this is better suited as a feature request… ? (=moving to a safer alternative than crypt, modernizing squid module…)
Actually, we’d expect to rely on the system’s hashing method. If passwords are being clipped to 8 characters, that suggests “DES” is being used. At the very least, I’d expect “MD5”, though that’s not ideal either. Modern systems use either “SHA512” or “yescrypt”.
Anyway, try applying this patch and see how it goes:
I don’t remember exactly how I set this up back when I was using Squid, but I clearly recall running into this issue. I do remember configuring auth_param basic program, though I’m not sure off the top of my head if that was the cause.
Anyway, give the patch a try and let me know how it goes.
Also, I highly recommend replacing basic authentication with digest authentication, as it is more secure—passwords are not sent in plain text, and it uses unique tokens (nonces).
To make this change, replace the first five lines of your current configuration with: