From owner-freebsd-security Wed Jul 7 5:33:16 1999 Delivered-To: freebsd-security@freebsd.org Received: from adelphi.physics.adelaide.edu.au (adelphi.physics.adelaide.edu.au [129.127.36.247]) by hub.freebsd.org (Postfix) with ESMTP id C8FAB1537A for ; Wed, 7 Jul 1999 05:33:10 -0700 (PDT) (envelope-from kkennawa@physics.adelaide.edu.au) Received: from bragg (bragg [129.127.36.34]) by adelphi.physics.adelaide.edu.au (8.8.8/8.8.8/UofA-1.5) with SMTP id WAA29578; Wed, 7 Jul 1999 22:03:09 +0930 (CST) Received: from localhost by bragg; (5.65/1.1.8.2/05Aug95-0227PM) id AA30295; Wed, 7 Jul 1999 22:03:01 +0930 Date: Wed, 7 Jul 1999 22:02:56 +0930 (CST) From: Kris Kennaway X-Sender: kkennawa@bragg To: Peter Wemm Cc: security@freebsd.org Subject: Re: Improved libcrypt ready for testing In-Reply-To: <19990707114108.58E8E78@overcee.netplex.com.au> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, 7 Jul 1999, Peter Wemm wrote: > > This is worth looking at. Do the password hashes have any distinguishing > > characteristics other than being 128 characters long? I'm wondering how > > they'd be distinguished in the password file, unless we add a $NT$ prefix. > Looking at /usr/local/private/smbpasswd, samba's NT-style shadow > password file: > > logname:2004:260AAF5FD661391EAAD3B345B51404EE:E9402F112D1BEC4978F943B55C11EB46: > Gecos Username:/home/logname:/usr/local/bin/tcsh The first of those hashes is the LanManager hash, which we do not want to include(that's the case-insensitive one which is trivially easy to break). Because they're hashes of the same plaintext, if you break the LM hash you get the upcased version of the password which you can then permute. > Also, we really do need some way to implement plugins that works on both > static and dynamic binaries. I would suggest that for dynamic binaries, > libcrypt would be compiled (ie: #ifdef PIC) to dlopen() the .so files > based on a config file. For static libcrypt, it would have to fork and pipe > the string to a static helper binary that returns the hash from the string. > That way /sbin/init will be able to verify any method for root password when > in non-secure console mode. > > I would suggest a /etc/crypt.conf or something that contains the prefix > and both a static and dynamic plugin. Hmm. This does sound like a good idea - it's much like the PAM system. The new libcrypt code is already very modular internally, so making it pluggable is the logical next step. Having the name token user-specified solves the problem of a third-party module treading on another module's name, at the cost of some extra configuration and non-portability if you want to migrate your passwords to a system which uses the colliding module. The solution I thought up was to have the name token as well as a random magic number (internal to the module and included as an extra field in the password) to statistically protect against collision. So you'd have $name$magic$rounds$salt$hash as your password format Kris > Cheers, > -Peter > -- > Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au > ----- "Never criticize anybody until you have walked a mile in their shoes, because by that time you will be a mile away and have their shoes." -- Unknown To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message