[Zope-PTK] Re: Proposal: password policy change

[Bill Anderson]

Shane Hathaway wrote:
> 
> Bill Anderson wrote:
...
> 
> > Here, I presume the following:
> >  o getPassword becomes _getPassword, implemented in the UserSource.
> 
> Not necessary.  getPassword() is already inaccessible via the web and
> DTML because of the getPassword__roles__ = () attribute.  When Brian
> finishes the new security assertion declarations, we'll be able to
> spell that in a friendlier way.

Ahh, sweet.

> getPassword() has the advantage that it can be overridden in a ZClass.

True.
 
> >  o mailPassword is defined in the UserSource
> >    this calls _getPassword() which returns the password.
> >
> > If the passord is encrypted (look at the way it is stored, or consult the policy .. or both), mailPassword would then
> > decide whether or not it needed to set new password, and return that, or just return the password.
> >
> > The UI just says, 'gimme the password'. It doesn't need to know, nor should it need to, the policy details.
> >
> 
> Correct, but the *user* needs to be informed of what's happening.  It
> would display either:
> 
> "Your password is being mailed to you."
> 
> or:
> 
> "A random, temporary password has been generated for you and is being
> mailed to you.  The temporary password will expire in 24 hours."


See below.
 
> > > 2) Sometimes an encrypted password is enough to break in.  Consider how
> > > many people use dictionary words as their password.  getPassword(),
> > > therefore, should never return an encrypted password.
> >
> > I've thought of that, and it would it be useful outside of an insecure policy? It could be done in the UserSource, and
> > changed to _getPassword (as mentioned above). This would prevent it from being called through the web. The
> > authentication being done in python, could access it.
> 
> A side note: there is a testPasswordValidity() method in
> portal_membership that can be used to enforce good passwords.

yeah, I've seen it.
 
> > > 3) The UI, which is mail_password_form, needs to be aware of the policy
> > > in effect and provide different instructions for each case.
> >
> > Why? The mail_passwordForm should hust have to call getPassword, which would be interpreted by the underlying mechanisms
> > as to whether or not it needs to just return it, or it needs to set a new one, and return that. This, it seems to me,
> > would also preserve the UI across other forms of authentication, such as against an SQL database (could be either
> > encrypted or CT), RADIUS, LDAP, etc.
> >
> > If the underlying functions have the werewithal to perform the required task, the UI is near universal.
> >  o User forgets password.
> >  o User asks for help
> >  o User gets instructions on how to log in, and what password to use.
> >  o User logs in.
> 
> Don't you think it's more user friendly to just provide details on
> what's going to happen next?  It's really not any more work on our
> part.

The UI can check the policy, and display details based on the set policy, no?
 
> Also, consider this example: I am a security conscious user and I know
> that passwords sent via email are readable by anyone along the long and
> twisty path.  But I forget my password, it's late at night, and I don't
> want to wake up the sysadmin.  I go to a page that says "click the
> button below to solve my password problem".  What is that supposed to
> mean?

If a policy were to have a 'property' of something like "forgotten_password_description" (or a better name), than the UI
(and the mailPassword method) can simply &dtml-forgotten_password_description; it. This has the nice advantage of a
completely fluid UI. You don't need to worry about changing the form if you create a new policy, or if you change it;
and I don't need to make a half-dozen forms for different policies that would be in the default options.

It boils down to me investigating exactly how policies are implemented, or should be. :-)=

Bill


--
Do not meddle in the affairs of sysadmins, for they are easy to annoy,
and have the root password.