On 10/14/2009 05:33 PM, Dave Page wrote:
> On Wed, Oct 14, 2009 at 9:50 PM, Kevin Grittner
> <Kevin.Grittner@wicourts.gov> wrote:
>
>> Can they check the box if the provided clients include password
>> strength checking? I'm just wondering if we're going at this the hard
>> way, if that really is the main goal.
>>
> No. Any checks at the client are worthless, as they can be bypassed by
> 10 minutes worth of simple coding in any of a dozen or more languages.
>
Why care? If the client is purposefully disabling passwords checks to
use a "weak" password - this is an entirely different problem from
somebody trying a weak password and being allowed. Circumvention of
process is always a risk, and should be dealt with as a human resources
problem. Why not stop the admin from disabling the security check when
they create their pgadmin password too? We can't trust anybody - right?
PAM does security checking client-side I think? I'm sure others do too?
I'm not saying server checks are worthless - but I think you are
exaggerating to say that client checks are worthless. Sending the
password in cleartext via SQL seems bad. Sending it encoded seems only
marginally better. Sending it in MD5 is good but means that password
strength needs to be done by the client. You are saying that it's worth
the loss of security in one area, to improve security in another.
Providing client checks in the "official" clients is probably sufficient
for your checkbox that you think is so important. Unless you think it is
impossible to circumvent process in any of these "other" databases that
do such a better job?
Personally, I don't think PostgreSQL is the best place to manage
passwords at this level anyways, beyond the basic usage. PostgreSQL
shouldn't need to know the password, and the password should still be
required to as strong as the organization requires it. Lots of other
solutions here - PAM, LDAP, Kerberos, ... How much of these solutions
should PostgreSQL re-implement?
Cheers,
mark
--
Mark Mielke<mark@mielke.cc>