Re: [Postfixadmin-devel] SF.net SVN: postfixadmin:[482] trunk

[David G. <da...@co...>]

Christian Boltz wrote :
> Hello,
> 
> Am Samstag, 22. November 2008 schrieb David Goodwin:
> ...
> > > - edit-mailbox might think the user wants to change the password
> > >   (because the password field isn't empty). This might result in
> > >   semi-random passwords if passwords are stored encrypted in the
> > >   database - the password hash will become the new password.
> > > (untested, but that's how I remember the code.)
> 
> > Well, int said there was a firefox extension which doesn't show stars
> > in a password field. The upshot being, that if you are a network
> > admin, and need to tell someone what their password is (or login as
> > them) then it's quite useful.
> 
> The usual solution for this problem is to simply change the password ;-)
> (doesn't solve the "login as them" part - but admins shouldn't do that 
> in general, and if the user wants them to do so, he can also tell his 
> password ;-)
> 
> And I still think displaying the password might cause problems as soon 
> as someone uses encrypted passwords and hits the "save" button...
> 
> Let me test it...
> 
> Test 1: encrypted passwords
> - go to edit-mailbox
> - click the save button
> Result: error message "the two passwords differ"
> 
> Test 2: plain text passwords
> - go to edit-mailbox
> - click the save button
> Result: password not changed, because edit-mailbox checks if it differs 
> from the old one
> 
> Test 3: plain text passwords again
> - go to edit-mailbox
> - "forget" to change "new password" field
> - enter a new password in "new password (again)" field
> Result: No password change and also no error message :-( because 
> edit-mailbox checks only the "new password" field for changes, not 
> the "(again)" field.
> 
> Testcase 3 is fixed now, but it will cause "the two passwords differ" 
> message in testcase 2 also.
> 
> Additionally, I get a "undefined variable" notice inside the password 
> field because the password is (intentionally) not read from $_POST. (Not 
> fixed yet, because I still think we'll need another solution, see c) 
> below.)
> 
> > Perhaps the config setting should be renamed, or have a comment
> > attached to make it obvious that it's only of any use if you store
> > plain text passwords.
> 
> If we really want to keep this feature (I'm still against it), then I 
> see three options:
> a) make it a separate setting ($CONF['SHOW_MAILBOX_PASSWORD_ON_EDIT'] or
> b) auto-disable it when password encryption is active  or
> c) add a "show password" link (with a $CONF setting to enable it, 
>    default should be disabled) which displays the password somewhere
>    (using flash_info or a alert() feeded with a AJAX request)
>    This would have some advantages:
>    - it works in every browser, not only if you have some extension
>    - it only transfers the password on request - which reduces the risk
>      (and number) of passwords in browser cache etc. a lot
>    - it fixes all the problems in edit-mailbox I described above
>    - it would easily allow to mail a notification to the user, which 
>      might be required by some people/companies for privacy or policy 
>      reasons
> 
> I think option c) is the best (or let's say "least bad") solution.

Hi,

c) sounds good, but I've no motivation to write it; so either we ditch
the change, or someone writes a patch...

(So far, Postfixadmin is AJAX free, perhaps it should stay this way?)

David.

-- 
David Goodwin 

[ david at codepoets dot co dot uk ]
[ http://www.codepoets.co.uk       ]