Re: Weak passwords and brute force attacks

On Tue, Dec 05, 2006 at 11:32:40AM -0500, Tom Lane wrote:
> Gavin Sherry <swm(at)linuxworld(dot)com(dot)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(at)mielke(dot)cc / markm(at)ncf(dot)ca / markm(at)nortel(dot)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 bind them...

http://mark.mielke.cc/