On Fri, 8 Dec 2006, Tom Lane wrote:
> 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.
I agree that your method makes sense but it's not what PAM seems to do.
I'm no security expert though. The OpenSSH daemon /seems/ to do the
same thing.
Thinking about it, I'm comparing apples and oranges. The systems PAM is
often being used for keep the connection open in the presence of an
authentication failure. They assume a human is at the other end and made a
typo. In our case, we basically terminate the connection.
Hmmm :-(.
> 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.
I agree. I had a think about what is involved there and as you say it
would make the code a lot more complex.
Thanks,
Gavin