Re: Rejecting weak passwords - Mailing list pgsql-hackers

On Thu, Oct 15, 2009 at 12:23 PM, Mark Mielke <mark@mark.mielke.cc> wrote:
> You miss my point (and conveniently cut it out). For users who accidentally
> break policy vs users who purposefully circumvent policy - the approaches
> must be different, and the risk management decision may be different.
>
> It's a lot easier to circumvent policy than most people (management
> specifically) realize. If your attempt it to absolutely prevent a determined
> competent individual from circumventing your policy - you need to do a LOT
> MORE than what you are suggesting.
>
> If you just want to prevent accidents - having the client software do the
> checks is fine.

I don't get it.  It's easy to circumvent client checks by using a
different client.  Circumventing server checks is really hard.  You
have to be able to hack the server.  It seems obvious to me that
putting the checks on the server is raising the bar by at least one
order of magnitude and more likely two or three.

Now, it's true that server-side checks on plaintext passwords are a
security risk - in paricular, even with SSL, they can be captured by a
modified server.  So from the point of view of the *employee*, sending
plaintext passwords may be less secure, because they don't know where
their password is going.  But from the point of view of the *server
administrator*, they are more secure, because the server administrator
believes (likely entirely correctly) that the odds of an employee
picking a bad password (perhaps by firing up psql, which is not
exactly a difficult-to-obtain utility) are higher than the odds that
someone will trojan his server and install a password capture tool.

If we were using some kind of real public key system and someone
suggested breaking it to add password complexity checking, I would
understand the outrage here.  But I don't understand why everyone is
so worked up about having an *optional* *flag* to force plaintext
instead of MD5.  I might be wrong here, but can't a determined
attacker brute-force an MD5 anyway?  The very fact that people are
suggesting that password checking might be feasible even on a
pre-MD5'd password by using a dictionary suggests that we're not
getting a whole lot of real security here.  And even if not, dude,
it's an *optional* *flag*.  Document that using it has certain
advantages and certain disadvantages, and let users make their own
decision about whether to deploy it.  If they make a bad decision and
get hacked as a result, tell them it's their own darn fault for
setting the flag.

I reiterate my previous opposition to the idea that "I wouldn't use
that feature" is a reason not to add it.

...Robert