From owner-freebsd-security Fri Feb 23 09:23:52 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id JAA22991 for security-outgoing; Fri, 23 Feb 1996 09:23:52 -0800 (PST) Received: from passer.osg.gov.bc.ca (passer.osg.gov.bc.ca [142.32.110.29]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id JAA22969 for ; Fri, 23 Feb 1996 09:23:44 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by passer.osg.gov.bc.ca (8.7.4/8.6.10) with SMTP id JAA27776; Fri, 23 Feb 1996 09:22:49 -0800 (PST) From: Cy Schubert - BCSC Open Systems Group Message-Id: <199602231722.JAA27776@passer.osg.gov.bc.ca> X-Authentication-Warning: passer.osg.gov.bc.ca: Host localhost [127.0.0.1] didn't use HELO protocol Reply-to: cschuber@orca.gov.bc.ca X-Mailer: DXmail To: Brian Tao cc: FREEBSD-SECURITY-L Subject: Re: Informing users of cracked passwords? In-reply-to: Your message of "Fri, 23 Feb 96 04:11:14 EST." Date: Fri, 23 Feb 96 09:22:49 -0800 X-Mts: smtp Sender: owner-security@FreeBSD.org Precedence: bulk Brian Tao wrote: > What is generally the best approach to handling a situation in an > ISP where a large of number of users (e.g., over 1000) are found to > have vulnerable passwords? > > We ran Crack on our master.passwd for a week or so, and after the > dust settled, over 1700 accounts were exposed. This is what we did: > > 1) Gave no warning to our users (we didn't want to alert hackers to > our crackdown on bad passwords) > > 2) Installed a new passwd binary linked with libcrack > > 3) Expired all affected passwords and set home directories to mode > 000 (mainly to deny access to the .rhosts file and public_html > directory One could use TCP/Wrapper to restrict the effectiveness of "r" commands to hosts that you trust thereby negating any entries users have put in their .rhosts files of hosts that you don't trust. > > 4) Required that new passwords be provided via voice call to our > customer support desk > > From previous discussions in security-related newsgroups, I am > under the impression that the best policy for a public-access site > is a clean sweep like this. No warning off the impending cut-off > date, and force the user to specify a better password. > > Does anyone have any counter-advice to the above method? > -- > Brian Tao (BT300, taob@io.org) > Systems Administrator, Internex Online Inc. > "Though this be madness, yet there is method in't" > > Regards, Phone: (604)389-3827 Cy Schubert OV/VM: BCSC02(CSCHUBER) Open Systems Support BITNET: CSCHUBER@BCSC02.BITNET BC Systems Corp. Internet: cschuber@uumail.gov.bc.ca cschuber@bcsc02.gov.bc.ca "Quit spooling around, JES do it."