This isn't really related, but has anyone implemented account lockout policies with Dovecot? ie: 5 wrong passwords and the account locks out. Is this possible with any of the MySQL or LDAP authentication back ends?

Paul

This sounds like something that should go in a pam module.

Yep - indeed. If your system supports pam of course :)

Then again, the convention net.wisdom at least -used- to be that this was a bad idea, because it became an easy DOS attack.

I take your point. But at the same time if there's no lockout mechanism a brute force attack will eventually guess the passwords.

Paul

On Thu, 9 Dec 2004, Ben Beuchler wrote:

On Thu, Dec 09, 2004 at 09:20:21PM +0000, Paul Reilly wrote:

...

...

Then again, the convention net.wisdom at least -used- to be that this was a bad idea, because it became an easy DOS attack.

I take your point. But at the same time if there's no lockout mechanism a brute force attack will eventually guess the passwords.

Tarpitting seems like a good approach, here.

I was just about to mail the same. That might be a nice post-1.0 feature. Especially if more software will use dovecot for authentication.

On Fri, Dec 10, 2004 at 08:56:03AM -0800, Dan Stromberg wrote:

1. If you get a good auth, you're in
2. If you get a bad auth, or the response takes more than n milliseconds/seconds, try the next password

Is there any reason to make tarpitting logic non-persistent? It seems a robust implementation would keep track of IPs that have failed logins. Removing the record, of course, at the first successful login.

-Ben

-- Ben Beuchler There is no spoon. insyte@emt-p.org -- The Matrix

On Fri, 10 Dec 2004, Ben Beuchler wrote:

On Fri, Dec 10, 2004 at 11:29:42AM -0600, Ben Beuchler wrote:

...

...

1. If you get a good auth, you're in
2. If you get a bad auth, or the response takes more than n milliseconds/seconds, try the next password

Is there any reason to make tarpitting logic non-persistent? It seems a robust implementation would keep track of IPs that have failed logins. Removing the record, of course, at the first successful login.

This would, of course, be potentially vulnerable to a distributed attack...

That depends on how smart the tarpit routine is. And I think you already need many thousands of machines before you can fill up a simple buffer with ips, in case of a very dumb tarpit algorithm. IPs don't take up so much space. IMHO, it's still better to try and slow them down (and perhaps protect the other services on the machine with the delays, so you can e.g. still receive email). Perhaps persistent caching would make things too complicated, the point is to slow them down, even if they have to do only 2/3 of their attempts with tarpit delay, you already succeeded.

It does look quite difficult to brute force over the internet, without any capable admin noticing millions of failed logins. Over an intranet it would probably be faster though, and they might be in before it's noticed.

My experience tells me at least SMTP tarpitting does help protect the servers when "#&%@! spammers visit your MTA instead of your baseball bat.