by mail.netbsd.org with SMTP; 18 Sep 2000 20:01:52 -0000
	id 3A9F64; Mon, 18 Sep 2000 16:01:49 -0400 (EDT)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
From: woods@weird.com (Greg A. Woods)
To: NetBSD Security Technical Discussion List <tech-security@NetBSD.ORG>
Subject: Re: Longer passwords
In-Reply-To: <20000918165626.C53834@netbsd.org>
References: <39C277982A5.6FF4ADMIN@mail.cordef.com.pl>
	<20000917160757.A10312@antioche.eu.org>
	<20000917234116.222904@proven.weird.com>
	<20000918165626.C53834@netbsd.org>
Reply-To: tech-security@NetBSD.ORG (NetBSD Security Technical Discussion List)
Organization: Planix, Inc.; Toronto, Ontario; Canada
Message-Id: <20000918200149.3A9F64@proven.weird.com>
Date: Mon, 18 Sep 2000 16:01:49 -0400 (EDT)

[ On Monday, September 18, 2000 at 16:56:26 (+0100), Andrew Doran wrote: ]
> Subject: Re: Longer passwords
>
> > Of course it would also be really cool if NetBSD would adopt the MD5
> > scheme used by the other *BSDs....
> 
> It (passwd.conf) has been in -current since early July. Blowfish encryption
> is not yet supported due to a lack of time at my end.

hmmm....  I missed that....  I've been paying less attention to -current
since 1.5 was branched.

On first glance it would appear that __md5crypt() will use the full
_PASSWORD_LEN bytes of the user input, which is good.  The documentation
in passwd.conf(5) and passwd(1) isn't very clear on any of this though.
(it would also be nice if passwd(5) also described the magic "type of
cipher" indicator and the meanings of the keys that follow it, as well
as of course including a cross-reference to passwd.conf(5) too!)

BTW, the syntax of /etc/passwd.conf itself is very poorly described.  A
"stanza" is a totally meaningless description.  Except for the example
it would be impossible to even guess at the proper form.  A file-format
manual page must be extremly precise in describing the syntax of the
records and fields it contains, as well as their meaning, or else it is
practially useless for many purposes.

The syntax kinda sucks big-time too.  A colon-separated format would be
far superior, especially given the context where it sits right in with
other extremely long standing and standardised colon-separated file
formats (i.e. /etc/*passwd and /etc/group).  The need for extensibility
can be easily handled by simply thinking about things the other way
around, i.e. instead of allowing multiple options per key, simply allow
multiple keys (just as is already permitted in /etc/passwd et al), and
an empty field can signify a wildcard "any" match (see my example
below).  In general multi-line record formats are much harder to deal
with even when syntactic sugar such as backslash continuations are
included.  Even getcap(3) format (ala login.conf!) would be a zillion
times better than what's there now.

Worst of all though is the choice of token to indicate the "default"
user.  Taking advice from the description of the legal field formats for
/etc/passwd I think it would be *HIGHLY* advisable to change this token
to be something that begins with a '-' (which is of course illegal at
the beginning of any login name) [or maybe just be a lone '-' to
indicate the default entry].

Here's what I might put in the "EXAMPLE" section of passwd.conf(5):

	root:user::md5
	wheel:group::md5
	-::localcipher:md5
	-:::old

In some ways this information is perhaps more suitably placed in
/etc/login.conf, or maybe conversely the password-related items should
be moved from login.conf to passwd.conf (eg. minpasswordlen,
passwordtime, etc.)?  I'd slightly prefer the former, in fact.

Sorry to pick login.conf completely apart, but I think this is a very
critical and central feature and the need for consistency is very strong
indeed!  The OpenBSD guys obviously didn't think very hard about this
before implementing it and I think it would be very wrong to follow this
very poor example of their design for NetBSD.

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>      <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>