[Feature] Bruteforce protection

[EtienneBruines]

We should find a way to defend the server against bruteforce password attacks at the LOGIN command. The way I currently tried to implement it (see #26 and #9), already protects against time-attacks (guessing the password by looking at the response time).

Do we want to:

• Use a public blacklist (don't know about any, but perhaps there is?)
• (Temporarily) Blacklist IP addresses that make X requests in a short time
• Temporarily disable the e-mail address that is being attacked
  • perhaps enable login only from IP addresses it used previously to log in successfully, notifying him per e-mail of the block.
  • perhaps the sysadmin should be notified instead, because most users will either think it's fake, or be freaked out entirely. Allowing login from known IP addresses might be a neat extra thing though.

I do think that that X should be high enough that a human cannot do it manually. 10 attempts per second, or perhaps 50 per minute/hour.

[alienscience]

If developers supply an Auth library for use with imapsrv, would sending emails and locking accounts be the responsiblilty of the Auth library?

Otherwise, I would be happy with something like a 10 second delay on login failure - most IMAP passwords are stored by IMAP clients and so this would not be annoying to a user. Would this be enough?

[EtienneBruines]

I thought it'd be best not to leave that up to the individual AuthStore implementations.

A 10 second delay looks like something that can be done. Would this be a delay for the IP address, the user, or both?

[alienscience]

The delay could be for anything that you would like. One thing to beware of with IP addresses are the large NATs used on mobile networks. It would be possible to mount an denial of service on groups of mobile users by sending bad logins through the NAT.