Date: Wed, 7 Jul 1999 22:02:56 +0930 (CST) From: Kris Kennaway <kkennawa@physics.adelaide.edu.au> To: Peter Wemm <peter@netplex.com.au> Cc: security@freebsd.org Subject: Re: Improved libcrypt ready for testing Message-ID: <Pine.OSF.4.10.9907072141180.13887-100000@bragg> In-Reply-To: <19990707114108.58E8E78@overcee.netplex.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.OSF.4.10.9907072141180.13887-100000>