nMagnus Hagander wrote:
> > Marko has pointed out repeatedly that a plugin can catch the worst
> > cases of insecure passwords even when given a pre-md5'd password.
> > So you can use a plugin that does it that way, or if you want you
> > can use a plugin that throws error on a pre-md5'd password. ?I do
> > not see a reason for us to add a boatload of questionable logic
> > that favors the latter approach.
>
> it lets you find some passwords, but it does not let you set a
> *policy*. As is often required by security policies etc.
I see three checks we are trying to do on passwords:
1) Password complexity enforcement/policies2) Password history - you can't reuse a password3) Account disable after X
incorrectattempts
#2 can be done by doing an MD5 on the server of the old password and
comparing it to what the client sent --- no need for a client change
there. #3 can be implemented in the server too.
#1 could be implemented in the server without client change if you are
willing to expand any wildcards in the password policy pattern, MD5
those, and check them against what was sent from the client, and this
only happens during password change. However, that only can check for
simplistic patterns, like trailing digit, etc, but not for things like
upper/lower case usage, etc. If you have such a policy, aren't you
already using LDAP or PAM, and can't those enforce it?
-- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
