Re: Weak passwords and brute force attacks

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Gavin Sherry <swm(at)linuxworld(dot)com(dot)au>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Weak passwords and brute force attacks
Date: 2006-12-05 16:32:40
Message-ID: 5684.1165336360@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Gavin Sherry <swm(at)linuxworld(dot)com(dot)au> writes:
> .... Instead, what we do is add up the different
> character types (lower, upper, digits, etc) and for each character type
> missing, we reduce the hypothetical password length: the theory being that
> the longer the password, the harder to guess.

Where did you get this design for a password strength checker?
It doesn't sound like it has much to do with the algorithms commonly
used for such things.

> 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.

> 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.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2006-12-05 16:45:04 Re: old synchronized scan patch
Previous Message Tom Lane 2006-12-05 16:25:20 Re: FAQ refresh