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

[Fabio Forno]

Shane Hathaway wrote:

> > The flag makes the duplication unnecessary.
> >
> > PolicyA: Encrypted
> > PolicyB: ClearText
> >
> > The mailPassword method could check the flag, and act accordingly, ie. set new password in case of PolicyA and mail
> > that, or just email the password in case of PolicyB. The getPassword method would just return the password, encrypted or
> > no. If you are running in 'secure mode', you get an encrypted password back. Not usefull most of the time, but it
> > hypothetically could be. In InSecure mode, you get the password back. Usefull for sending a user their password, but
> > little else.
> 

Yes the flag (in my local modifictaions I put it in portal_properties as
a boolean falg, whose name is encrypted_passwords) could make the
duplication unecessary, but actually these two methods have a pretty
different behavior and conseguences and I'd like two different names
(just a question of aesthetics ;). To resume the modificatios I've done: 
- added mailNewpassword and encodePassword into RegistrationTools
- made the Portal ZClass mail_password test the flag and decide which
password policy use
- modified the logged_in method in order to manage the first login after
the mailNewPassoed invocation
  In this case:
  - It shows a change password form as the first login (actually they're
managed together)
  - It resets the temp_password (added it to system properties)
  - It explains that the mailed password is just a one time pwd and the
user can choose to mantain the old one or set a     new password


> Comments:
> 
> 1) I'd have to agree with Steve; I don't see a need for scheduling.
> What do you think, Bill?
>
Neither I, I think that the one time passsword is enough
 
> 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.

Who actually can call getPasswd()? 
 
> 3) The UI, which is mail_password_form, needs to be aware of the policy
> in effect and provide different instructions for each case.

As I've said also logged_in must be aware (I my modification
Portal::mail_password is awre, not mail_password_form)


ByE,
FF