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.