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

[Bill Anderson]

Shane Hathaway wrote:
> 
> Fabio,
> 
> > While integrating the PortalMembership  system I had
> do with a different
> > password policies: PM stores encrypted passwords and
> obviously hasn't a
> > getPassword method which unuseful in this case. To
> manage the
> > mail_password_form it skips the problem of reading
> it generating a new
> > password and replacing the old one. I think this is
> the most secure way
> > to handle passwords and should be implemented also
> in the standard PTK
> > portal_registration. We need just to eliminate the
> getPassword method,
> > and modify the mailPassword (I propose to rename it
> mailNewPassword)
> > method in order to:
> > 1) generate a new pwd
> > 2) set it
> > 3) mail it
> 
> This is an excellent idea.  I would suggest that it be
> implemented in a different way, however.  Consider:

So where was everyone when I called for discussion on this very topic a few weeks ago? ;^)=

 
> 1) People will forget their passwords and need a way
> out.  The most "user friendly" way out is for them to
> receive their password again via e-mail.  Of course
> this is terribly insecure, but slashdot and many
> others do it this way, so those who run PTK sites will
> expect this to be an option.

True, though these sites are diminishing in number. As users and administrators become more aware of the problems with
storing cleartext passwords, they quite making and using sites such as that...or whine to the admins until they change
it. ;^)

> 2) If we allow passwords to be instantly reset by
> anonymous users then that capability will be abused by
> intruders.

While this is true, in practice it isn't as common as you would think. Generally, it requires more thought and use of
skill than most script-kiddies (really the ones who would do this in most cases) possess. See below for commentary.


> In order for your plan to work, therefore, we need to
> provide the option to set a temporary password.  This
> temporary password would be in addition to the user's
> normal password.

I have considered that, and doing something like a temporary password would require the use of a scheduler, such as
Xron. Though a fine product, I want to keep Dependencies down. It already needs ZPatterns and LoginManager.

I have considered setting a hint (as many sites do). Such as a question and answer. If the person answers the question,
they get a new password sent. If not, they don't. This largely eliminates any real threat from abuse by script-kiddies.
This, too, could be part of a 'policy'. I've seen the hooks for a policy set-up. but haven't delved into them too much
yet. I have focussed more on providing a base level of functionality, with the hooks needed to grow, and the interfaces
for user management.


> Scenario 1:
> 
> a) User tries to log in but forgot password.
> b) Clicks "Set temporary password".
> c) Receives e-mail with temporary password.
> d) Logs in with temporary password.  User is either
> required to set a new password immediately, or the
> temporary password becomes the permanent password.

This Requires triggering actions, and a state of in-betweenness, or a scheduled activity such as setting an xron event
to change password at now+time period. I've commented on the latter elsewhere. The former could be done using Triggers,
but I won't ba eable to do it for 1.0, though as usual, patches welcome (diff -u format on python source, if any changes
made there please). :)

 

> 
> Scenario 2:
> 
> a) Hostile intruder wants to attack Joe's account.
> b) Intruder uses an HTTP request generator to cause
> the "temporary password" function to be executed
> 1,000,000 times for joe's account.
> c) Joe's mailbox overflows.  The most recent temporary
> password is lost in cyberspace.
> d) Joe goes to sysadmin and asks for help.
> e) Sysadmin says "just use your old password, it still
> works" or "just delete the messages and request a new
> temporary password".
> f) Joe does, it works, and the intruder is (mostly)
> thwarted.

One Solution: 
 The password change can only be activated
 once per day. Now it takes 1,000,000 days
 for the HI to try his attack.


I would appreciate it if you two would codify some of these ideas and proposals on the wiki. :) 

Handy for future reference, those wikis are.

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