[Date Prev][Date Next]
Re: Server side delay for bad passwords?
On Thursday 07 February 2008 21:37:20 Dan White wrote:
> I'd only want a delay when a user/attacker has entered a bad
> password, similar to the way a UNIX shell introduces a delay.
The UNIX shell (well actually, the login binary on my UNIX clone OS, which
uses PAM) doesn't introduce a delay for a bad password, but under any
circumstance where the credentials supplied are incorrect.
Implementing it only for when the password is incorrect is typically
discouraged by security researchers, as this is information disclosure (which
could assist an attacker in gathering information for performing an attack).
For example, a few years back, OpenSSH specifically added a patch to ensure
that when OpenSSH authenticated via PAM, that the delay would be exactly the
same whether the user existed or not.
Now, if you really want to introduce a long delay when any bind fails, I think
you will experience problems.
> concern is that the faster I tune my server, the more likely it
> will become that an attacker will brute force a password.
IMHO, you should rather ensure that entering the incorrect password more than
a specified number of times results in the account being locked out. If your
SASL mechanism can't do this, take that to their list.
> > Don't know, but the manpage doesn't mention "simple", only "bind".
> I've seen mention on the list before that ppolicy does not apply
> to SASL binds, and that's been my experience in testing as well.
Naturally, as the p in ppolicy is for password, in the SASL case, the LDAP
server doesn't have the password (in most cases). However, for the simple
bind case, I would use ppolicy with lockout.
But then, I authenticate 200 users/second, and I can't tolerate delays or more