Subject: Re: Chapter 8 security
To: Steven M. Bellovin <smb@research.att.com>
From: Thor Lancelot Simon <tls@rek.tjls.com>
List: current-users
Date: 04/16/2004 15:18:31
On Fri, Apr 16, 2004 at 03:12:38PM -0400, Steven M. Bellovin wrote:
> In message <20040416190325.GA26196@panix.com>, Thor Lancelot Simon writes:
> 
> >
> >1) The password-strength requirements earlier in the document (you'll need
> >   to modify /etc/passwd to enforce these restrictions, but I believe you
> >   can in fact use the cracklib package to do this quite easily)
> >
> 
> There's another section that speaks of password generation.  See pkgsrc/
> security/apg, which implements a NIST scheme for password generation.

I have to note that apg's code is *awful*.  But I've recommended it in
the past, assuming it weren't run with privilege (for example: use apg
to generate a password, run in a constrained environment; have something
*else* set that password into place using privileges), so, yeah, I
agree with you.

However, note that just using apg to generate users' passwords isn't
good enough.  If you rely on that, you will need to chmod the "passwd"
binary so that normal users cannot run it; and if I were auditing such
a system, and I felt particularly strict, I'd note that the *root*
password could still be set to an unacceptable value...

If I were the auditor-from-hell, I'd probably insist that this requirement
be enforced *by crypt(3)*, so that no matter what the source of a change
to the encrypted password were, an unacceptable password could never
allow successful authentication.  But I have some experience with such
audits, and I think it'd be an unusual auditor who would be clever enough
to realize that the requirement, as written, may actually be that strict.

Thor