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.
My 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 connection build-up.
Regards, Buchan