[x500standard] Re: New draft on password policy
- From: Howard Chu <hyc@xxxxxxxxxxxxxxx>
- To: x500standard@xxxxxxxxxxxxx
- Date: Tue, 22 Sep 2009 18:09:57 -0700
David Chadwick wrote:
Hi Howard
Hi David, sorry for the late reply, just got home after LDAPCon in Portland.
Looking over the responses, everything looks good. At this point I would just
ask that some of the areas where I had questions before have their explanation
/ motivation included in the document.
1) relying on clients to know that they should be using an encrypted
password, and to know which algorithm to use, seems impractical in the
real world. IMO whether and how the password is encrypted should be a
matter private to the DSA.
we still allow this as an option, but we think it is more secure if the
directory never knows the user's password so is not able to store it in
audit trails or anywhere. Hence we think this option should be allowed.
OK. Since a lot of LDAP deployments are being used to centralize
authentication (and thus, secrets for LDAP, Kerberos, and SASL are being
stored here) this perspective was unexpected. So I think it would be useful to
note this motivation in the document.
c) noPasswordSlot error - this appears to be an open invitation to
Denial-of-Service. What if the last password was known to be stolen and
needs to be changed immediately?
we have fixed this by adding a pwdMinTimeInHistory attribute (default
zero secs) which allows a password to be removed from the history list
if the min time has been exceeded. The reason for allowing admin to set
a non-zero time is to stop users recycling through passwords quickly in
succession so that they can use their old password again immediately
after it has expired. Admins that want to allow this can, by keeping the
default time of zero.
OK.
3) Password Policy, section 18.1.3:
a) Maintaining a pwdExpiryDate attribute is redundant information and
imposes undue overhead. E.g., when the pwdExpiryAge is changed, the
pwdExpiryDate for every affected entry must be recomputed and rewritten
into the directory. It's best not to store this attribute at all, and
always compute its value on the fly as needed.
This is cpu vs storage, a recurrent theme in computing. If we change the
current text "Its value may be obtained by addition of the pwdExpiryAge
to the pwdCreationTime of the entry or set by an administrator."
to
"It is an implementation option whether the value is dynamically
computed by addition of the pwdExpiryAge to the pwdCreationTime of the
entry, in which case it does not need to be stored in the directory
entry, or is set by an administrator, in which case it shall be stored
in the directory entry".
it should solve your issue.
Sounds good.
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.
We have changed this into a set of password quality attributes, which
include: max length, forbidden vocabularies, mandatory character sets,
and forbidden URL dictionaries.
Sounds good. I'll want to look at making the same additions to the LDAP draft.
I've also reviewed your later followup email and have nothing else to add,
thanks.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
-----
www.x500standard.com: The central source for information on the X.500 Directory
Standard.
Other related posts:
