Re: Server side delay for bad passwords?

[Buchan Milne <bgmilne@staff.telkomsa.net>]

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