From owner-freebsd-isp Tue Sep 10 07:03:33 1996 Return-Path: owner-isp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id HAA17281 for isp-outgoing; Tue, 10 Sep 1996 07:03:33 -0700 (PDT) Received: from house.multinet.net (house.multinet.net [204.138.173.37]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id HAA17264 for ; Tue, 10 Sep 1996 07:03:28 -0700 (PDT) Received: (from graydon@localhost) by house.multinet.net (8.6.12/8.6.12) id JAA08742; Tue, 10 Sep 1996 09:53:08 -0400 Date: Tue, 10 Sep 1996 09:53:07 -0400 (EDT) From: Graydon Hoare To: Peter Childs cc: freebsd-isp@freebsd.org Subject: Re: Recommendations on password management. In-Reply-To: <199609101958.TAA04597@al.imforei.apana.org.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-isp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Tue, 10 Sep 1996, Peter Childs wrote: > In article <514d7d$40v@al.imforei.apana.org.au> you wrote: > > if you implement something too hacked up it may not scale too well, > but if you use something too large then it may just not be the > most cost/time/hastle effective way :) > > Well thats pointed out more questions than answers.. but i'd be > interested in the replies to this one. I'm at the stage where I'm considering my options for this exact problem, and I'm slowly edging towards a kerberized setup. Now out site is probably abnormal in that we've got a dial group of maybe 10 (!) lines and mostly service business clients who want to log in and pretend they are a virtual mail server, or update web pages we're holding for them. The dial group is on a bunch of netblazers which do speak kerberos... the current setup is to have one-line passwd files tftp'd around the network for each user and stored in a little users directory, but it's not necessary for all users who have email accounts to also have logins to the web server (undesirable security hole possibilities). The problem with using eBones (kerb) is that wu-ftpd-academ knows sweet nothing about kerberos, and neither does popper. However, since passwords are flying all over the network in plaintext anyway, I have devised a semi-solution which gives me better-than-it-could-be security without breaking all user tools. there's a little bit of perl glue, but basically the user only _thinks_ they have one password, but in reality there are local passwords for popper, local passwords on the shell/ftp accounts on the web machine, and kerb passwords stored in the kserver (which happens to be running on the mail server) users can use eudora to "change their password" which I am assuming won't happen as often as they login, and a script uses the foolishly simple eudora passwd-changer protocol to talk with SYS_setuid(), then kinit, then passwd, then passwd -l, then kdestroy (no proof that any of this works yet, mind you), it then uses a configuration file to pull users who are supposed to be able to use the web machine out of the master.passwd and squirts them across the lan via an rsh web -k -x pwd_mkdb. This is cool cause the users on the mailbox are all /nonexistent login shells, and telnetd/ftpd on all the machines don't accept root, standard rlogin is disabled, and rlogin -k -x and su are as secure as eBones can make them (haven't looked at the code). Essentially it pushes admin security and daily PPP login security into the kerberos realm (no pun intended) and leaves ftpd and popper and telnetd on user accounts nice and open, while centralizing password management for the netblazers. I am guessing this would scale for a while, but probably nowhere near the level some of the ISPs on this list are operating at.