Re: Rejecting weak passwords

On 09/29/2009 09:07 AM, Gurjeet Singh wrote:
> On Tue, Sep 29, 2009 at 4:49 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us
> <mailto:tgl(at)sss(dot)pgh(dot)pa(dot)us>> wrote:
>
> Josh Berkus <josh(at)agliodbs(dot)com <mailto:josh(at)agliodbs(dot)com>> writes:
> > Hmmm, that would be a useful, easy (I think) security feature:
> add a GUC
> > for failed_logins_allowed.
> And the counts would be tracked and enforced where?
>
>
> Combining this with other suggestion:
> .) Provide a GUC failed_logins_allowed
> .) Add MAX FAILED LOGINS option to ADD/ALTER USER, which defaults to
> the GUC if not provided in the command.
> .) Track per-user failed attempt counts in shared catalog, and reset
> on a successful login.
>

Reset on successful works _against_ the goal of preventing brute force
attacks. Brute force attacks try until successful.

I read Josh's original suggestion to eventually evolve to "if a
particular user account from a particular IP address uses the wrong
password more than N times in T minutes, than the IP address is locked
out for U minutes." This is the *only* way of significantly reducing the
ability of a client to guess the password using "brute force".

It works pretty successfully in other systems. I know when I forget my
voice mail password and I try five times, my account gets locked out for
24+ hours unless I request a password reset from our support
organization. It is a pain in the butt - but it means that somebody
trying to guess my password either has to get it right in a few short
guesses, or they are out of luck.

Still, all of this seems a little bit over thought out to me, as unless
one goes to this extreme - of actually blocking connections from an IP
for a period of time - the ability to brute force passwords is already
limited by network capacity, network latency, and protocol restrictions.
md5 might be "broken" from the perspective of a super user having access
to the md5 and having access to hardware accelerators (GPU), but brute
forcing from a client to a server is still limited to thousands of
attempts or less per second. This particular aspect of PostgreSQL has
not concerned me. I tend to think that anybody who exposes their
PostgreSQL to the Internet directly is asking for trouble no matter how
hard pgsql-hackers tries to protect them. On my own network, there are
so many other ways of getting at the passwords - including the crypt()
passwords being visible over NIS using "ypmatch", that this is really
the least of my concerns. We have employee agreements in place that
prevent the use of "hacking", and outsiders are not supposed to have
access to our network.

Point being - if you want to really be effective compared to what we
have today - you need to go all the way. Half way is useless.

Cheers,
mark

--
Mark Mielke<mark(at)mielke(dot)cc>