[1799] in WWW Security List Archive
Re[4]: Is password good enough?
daemon@ATHENA.MIT.EDU (Mike Bremford)
Tue Apr 9 15:02:18 1996
Date: Tue, 9 Apr 1996 17:03:51 +0100
From: Mike.Bremford@mail.bl.uk (Mike Bremford)
To: "Robert S. Muhlestein" <robertm@teleport.com>
Cc: jazayeri@hpcc117.corp.hp.com, www-security@ns2.rutgers.edu
Errors-To: owner-www-security@ns2.rutgers.edu
Information on the free SSL implementation is available at:
http://www.psy.uq.oz.au/~ftp/Crypto
There are version of mosaic, telnet, ftp, NCSA httpd and Apache httpd floating
around with SSL. I've used the apache server only, but its very easy to set up
and use, allowing full 128 bit key thingies (although being in the UK I can only
get a 40-bit version of Netscape to talk to it).
The other catch is *currently* getting a certificate signed by VeriSign (and as
far as I know the other certifying authorities have similar policies) for a
product using free SSL is not possible - VeriSign won't accept it. Obviously if
you're planning on just using a secure telnet internally, its not a problem.
Cheers... Mike
--------------------------------------------------------------------------------
> Surely if you use a 'secure' interface like SSL, "sniffing" the passwords
while
> in transit won't be a problem. I know you can patch telnet and other such
> programs to use SSL as well for the same reason.
Humm.. An SSL telnet patch. I'd love to know where I could find such a
thing.
> Also, if you create a group, say "http", that your httpd daemon runs as, and
> make the .htaccess and .htpasswd files read only by that group, and not by
> anyone else, then they are as secure as shadow passwords on a UNIX system. (ie
> fairly secure).
This is exactly what we do at Teleport. Everyone is in group "users" and
the server runs as someone else in a different group. We have server-side
includes active, but have hacked out the <!--#exec cmd=""--> option and
restrict the cgi-bin directory. Otherwise, there is nothing stopping
someone from <!--#exec cmd="cat /path/to/some/file"-->ing the information
from a file not normally accessible to shell users. There is also nothing
stopping users from randomly "killing" off server children, etc. Most
already know this, but it couldn't be repeated enough.
By the way, using method like Mike mentioned is also how we protect
certain files to which some CGI scripts must have write access (i.e.
counter data files, guestbooks, etc. I use something like the
following (please let me know if you see any reason this is
insecure):
chgrp users <filename> (all users are in group users, including most
admins)
chmod 606 <filename> (sets read-write for owner and world, but blocks
everyone in group users, which is effectively
everyone)
Thanks,
Robert Muhlestein
Teleport Creative Services
CGI/Java Guy
cgi@teleport.com
