The following reply was made to PR bin/10206; it has been noted by GNATS.

From: David Maxwell <david@crlf.net>
To: gnats-bugs@netbsd.org
Cc: security-officer@netbsd.org, gnats-admin@netbsd.org,
	netbsd-bugs@netbsd.org
Subject: Re: security/10206
Date: Mon, 15 Aug 2005 14:22:46 -0400

 Elad wrote:  
 >  There are also plenty of PRs about system integrity, and we don't enable
 >  Veriexec by default. The way I see it, NetBSD should provide the tools
 >  for an admin to customize the security of her system the way she sees
 >  fit.
 
 Agreed. Currently, the admin can not customize her system to either
 request or require good passwords.
 
 >  This whole PR is based on the assumption that we are not doing anything
 >  to prevent brute-force password cracking.
 
 No. It affects passwords that will be exposed over NIS, shared with
 other systems that don't use shadow password files, or used in other
 protocols that expose a hash.
 
 Brute-force is relevant to this, partially, but preventing brute-force
 attacks would not eliminate the desirability of good passwords.
 
 >  How many guesses does it take to pick a password? Should we be enforcing
 >  this for *all* users, even those who use NetBSD in environments where
 >  these concerns no longer hold?
 
 No, we should provide the tools for an admin to customize the security
 of her system the way she sees fit. Right now, we don't provide the
 tools.
 
 >  Unless you are taking measures to prevent an attacker from infinitely
 >  trying all password combinations, your password *will* be cracked. This
 >  is why many people use public keys, and why many admins care about
 >  rate-limiting login attempts; *this* is where we should aim if we want
 >  to have a take on solving this problem.
 
 If you're concerned about Internet-accessible hosts, what you say is
 true, but there are many other system environments.
 
 >  IMHO, enforcing 10-char, upper/lower/digit/punctuation passwords is
 >  archaic. And given JtR allows you to specify possible password patterns,
 >  and the power of today's computers, and the ability to no transparent
 >  processing distribution, I don't see how any of the suggested in this
 >  patch solves the problem.
 
 The 'power of today's computers' may impact DES, but impact other hashes
 less. 
 
 Additionally, many corporations have Security Guideline Documents, about
 what types of passwords an acceptable system may allow. Whether right or
 wrong about the requirements of passwords, we want to make NetBSD usable
 in those environments.