[3474] in WWW Security List Archive
Re: Password protected HTML
daemon@ATHENA.MIT.EDU (Robert S. Muhlestein)
Wed Nov 6 15:21:23 1996
Date: Wed, 6 Nov 1996 09:26:07 -0800 (PST)
From: "Robert S. Muhlestein" <robertm@teleport.com>
To: sameer <sameer@c2.net>
cc: Bert Carroll <bc17684@90.deere.com>, www-security@ns2.rutgers.edu
In-Reply-To: <199611060343.TAA18268@atropos.c2.org>
Errors-To: owner-www-security@ns2.rutgers.edu
On Tue, 5 Nov 1996, sameer wrote:
> Using Apache and/or Stronghold you can easily replace the
> mod_auth.c module to do whatever authentication you like. In your case
> calling the Solaris pwdauth (the Solaris version of pwdauth.. I only
> know SunOS) function.
Suprise! :) Sun removed this "security hole" in Solaris. No pwdauth. No
underlying pwdauth lib functions for calls to "crypt" in PERL or C. That's
right, no using regular "##" and "#$" indicating you want to use the passwd
file. Oh, no pwdauth.rpc daemon at all.
I guess this makes sense. This prevents people from making brute force
attacks on the passwd file even if it is shadowed. I just wish I'd have
know before every script calling crypt to authenticate a user by password
suddenly broke. If you use this function and have recently upgraded, well,
you will know what I'm talking about.
This relates to www for those who may have allowed certain CGI and other
functions to authenticate a user using the one-way crypt comparison. In my
case, we had to essentially recode our own pwdauth equivalent that we locked
down tight before setting the suid/sgid bits. Really scary stuff. No
wonder Sun wants out of that game. They must figure we can hang ourselves
if we want to without their help.
Anyway, here's to OO! We simply had to rewrite the one custom PERL5 module
that was calling crypt, and therefore the underlysing pwdauth syscall, and
presto! All the CGIs calling this method came alive.
> > I want to use the password file that comes with Solaris rather than the
> > standard one used by Netscape and other webservers. What I am really
> > after is the ability to "age" a password and / or check it against a
> > dict file before allowing the user to set weak passwords.
Netscape doesn't seem to allow you to specify the format of the passwd file
other than like the original NCSA:
user1:LHkljkKLlj
user2:somepassword
Putting all your system passwords into this format would essentially blow
open the same SunOs non-shadowed password hole on your system. But...
Really, I'd suggest making sure you are using shadowed passwords and
find some other way than relying on Netscape for this authentication.
Messing directly with the password file from the open web allows people
some "guessing" ability. However, I've found that usually the overhead
of the web server and logging create enough overhead and audit ability
to keep the black-hat crackers away from this type of one-way
authentication. I'd suggest writing one-way password authentication
CGI script and restrict access using this script. This lets you run shadowed
passwords and provides authentication with "acceptable" risk.
Rob
----------------------------------------------------------------------
Robert S. Muhlestein
Web Technologist
NIKE, Inc.
Work: robert.muhlestein@nike.com
Personal: rmuhle@q7.com
Old: robertm@teleport.com
(Opinions and comments are my own, not NIKE's.)
----------------------------------------------------------------------
