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@sss.pgh.pa.us 
> <mailto:tgl@sss.pgh.pa.us>> wrote:
>
>     Josh Berkus <josh@agliodbs.com <mailto:josh@agliodbs.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@mielke.cc>