Gavin Sherry <swm@linuxworld.com.au> writes:
> On Tue, 5 Dec 2006, Tom Lane wrote:
>> Gavin Sherry <swm@linuxworld.com.au> writes:
>>> The second mechanism is the delay on authentication failure.
>> 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.
> That doesn't seem to be what PAM does, at leasts in the default config.
> What they do do is to sleep for a random period between no sleep and the
> threshold, so that the attacker cannot guess the appropriate time to wait
> before hanging up.
No, you missed my point: the attacker doesn't need to guess what the
failure delay is. As long as he has a pretty good idea what the
*success* response time ought to be, he can give up as soon as a bit
more than that has elapsed. Yup, it's probabilistic because there's
some uncertainty about the backend launch time, but what does he
care? Brute-force password attacks are always probabilistic.
A delay in the failure case is only helpful if you have some active way
to prevent the attacker from making another try before the delay has
elapsed. Which is something we don't have, at least not without
introducing a lot more complexity/fragility into the postmaster than
seems wise to me.
regards, tom lane
