Fwd: Re: [x500standard] Re: New draft on password policy

Food for thought re: pwdQuality checking rules, not sure where this discussion 
needs to be centralized. One way or another, I would like to get a new 
revision of the LDAP ppolicy draft written up with some of the additions I've 
already outlined and move ahead on implementation.

-------- Original Message --------
Subject: Re: [x500standard] Re: New draft on password policy
Date: Tue, 14 Jul 2009 17:35:03 -0700
From: Howard Chu <[email protected]>
To: [email protected]

Howard Chu wrote:
> Section 18.1.6:
>     a) why is pwdQualityRule single-valued? Without an initial set of rules to
> serve as examples, it's difficult to evaluate the usefulness of this
> attribute. I would expect that multiple orthogonal rules will be defined and
> that a policy would allow combinations of these rules to be chosen. IMO this
> attribute should be multi-valued and at least one or two prototypical rules
> need to be part of the spec. As an example, a rule that validates the
> plaintext of a password against a regular expression would be useful.

In thinking about what custom modules we've implemented for this in the past,
I propose a couple rules for usage. First of all, assume that pwdQualityRule
is multivalued, where each value defines a single type of rule, and a given
password must pass every rule to be valid.

    regexp: expression
	Succeeds if the password matches the expression
    dict: URL
	Succeeds if the password is not found in a word list residing at the given URL
    scan: LDAPURL
	Succeeds if the specified LDAP query returns no matching entry

I suppose the use of an LDAPURL here may be inconvenient, but I don't recall
seeing X.500 URLs in wide use. In practice I would prefer a Compare operation
which must return CompareFalse to succeed, but the LDAPURL format is too
braindead and only supports Searches. (I have an overlay for OpenLDAP which
supports this feature: do a compare on a magic DN and the argument is
processed with cracklib.)

"dict" may be too simplistic since it presumably wouldn't account for case
variations and other simple transformations of common dictionary words. Again,
in OpenLDAP we punted this to an externally loadable module because spelling
out a variety of transformations here was too awkward. Since the most commonly
used module just calls cracklib, perhaps "cracklib" itself should be one of
the pwdQualityRule types.

-- 
    -- Howard Chu
    CTO, Symas Corp.           http://www.symas.com
    Director, Highland Sun     http://highlandsun.com/hyc/
    Chief Architect, OpenLDAP  http://www.openldap.org/project/