Re: Weak passwords and brute force attacks

On Tue, Dec 05, 2006 at 11:32:40AM -0500, Tom Lane wrote:
> Gavin Sherry <swm@linuxworld.com.au> writes:
> > Now, in the presence of encrypted passwords being sent across the wire, we
> > can't do anything. So, we export the password strength tester to libpq.
> As already noted, that seems approximately useless.

Telling the users they are being stupid isn't useless - but yeah, it sounds
like a domain that should be covered by a tool other than PostgreSQL.

PAM sounds about right, and PAM already has this functionality.

> > The second mechanism is the delay on authentication failure. The problem
> > here is that a distributed application could attempt to brute force guess
> > a password for a role. This could be fairly effective on a high speed LAN.
> > So, the usual approach is to delay sending the failure message to the
> > client for some period of time (specified in the patch by
> > auth_failure_delay) to slow the progress of the password guesser.
> This is a waste of effort, unless you propose to put the delay into both
> the success and failure paths, which hardly seems acceptable.  Otherwise
> a guesser need only abandon the connection attempt after X microseconds
> and try another password.

Not a waste unless the caller isn't going to allow for missing a valid
password after X+1 microseconds that was late due to network latency,
and CPU scheduling. This isn't a real time system. Even halfing the
number of password attempts doubles the time required to search a
particular pattern space. Double is good. It's a tried and true method
used by security systems around the world. Another tried and true
approach is to deny a client for a period (10 seconds?) if they enter
the same wrong password three times in a row. It really puts a wrench
in the gears for any brute force strategy.

But again, I would still prefer to avoid username/password entirely if
security is a real concern. SSL certificates, Kerberos tokens, or
operating system credentials (passed over UNIX sockets) appeal to me
much more.

If the patch is really small, and really portable, I would suggest it
be adopted. For example, adding a sleep(1) after invalid passwords doesn't
significantly add to the maintenance cost for the code, and it has a
positive effect. Getting too complicated, however, would be a problem
domain that PostgreSQL shouldn't be trying to address.

Another perspective... :-)

Cheers,
mark

-- 
mark@mielke.cc / markm@ncf.ca / markm@nortel.com     __________________________
.  .  _  ._  . .   .__    .  . ._. .__ .   . . .__  | Neighbourhood Coder
|\/| |_| |_| |/    |_     |\/|  |  |_  |   |/  |_   | 
|  | | | | \ | \   |__ .  |  | .|. |__ |__ | \ |__  | Ottawa, Ontario, Canada
 One ring to rule them all, one ring to find them, one ring to bring them all                      and in the darkness
bindthem...
 
                          http://mark.mielke.cc/