|
From: David G. <da...@co...> - 2007-10-07 08:32:39
|
> > As these are the passwords for the admin user, how about we change is
> > so admin passwords are _always_ encrypted with something decent? As
> > admin passwords aren't used for mailboxes, it wouldn't have any
> > impact outside of postfixadmin.
>=20
> Would be an idea. However, we'll need a way to handle existing=20
> unencrypted passwords.
>=20
That could be done through some sort of generic 'upgrade' script -
which it appears we'll need....
> > My grievance with this is that when ever an admin is edited, I think
> > your previous patch, implied that a users password had to be
> > changed/set. Which is horrible.
>=20
> No, the password does not need to be touched. See my change in r123:
>=20
OK.
> > If we're thinking of older ones, then we'd have to use=20
> > something like PEAR::DB or PEAR::MDB2 - which emulate
> > prepared-statement-ness.
>=20
> Ah, the old question of using an abstraction layer. I'm still not sure=20
> if we really need it - but having some helper functions (for example
> insert("table", array ("field1" =3D> "value1", "field2" =3D> "value2")
> that create database statements might be a good idea.
>=20
Well, we could always bundle mdb2 / pear db with postfixadmin - this
would remove any requirement for admins to set it up etc.
> > I added a min_password_length config setting in.... which should help
> > too ($CONF['min_password_length'])
>=20
> Yes, I already hit this in the test installation on my laptop ;-) (which=
=20
> doesn't need strong passwords - it's not connected to Postfix at all).
Note minor change to config.inc.php[.sample]
David.
--=20
David Goodwin=20
[ david at codepoets dot co dot uk ]
[ http://www.codepoets.co.uk ]
|
