> From: Todd Lyons
> > How to block stolen passwords automatically:
> > https://github.com/Exim/exim/wiki/BlockCracking
>
> Lena, one corner case of this is when a legitimate user has one device
> with the wrong password. Picture a typical small office where two or
> three people using a small NAT router to connect to their business
> class DSL. One person changes their password and they fix it on their
> iphone because they have to leave to go do something. They leave.
> Their outlook is still open on their computer and someone comes by to
> check something in the email. Outlook doesn't seem to be working
> right so they hit the Send/Receive button multiple times. On the exim
> server, the limit for bad user/pass combination gets hit and the ip
> gets added to the blacklist. Now the whole office is blocked from
> sending email.
>
> I'd like to ponder if there is a way to detect that the same incorrect
> password is being sent over and over (indicating a misconfigured
> device) as opposed to random passwords (indicating brute forcing). To
> my knowledge the actual password nor a hash of it is not made
> available anywhere except to the authenticator section. Can you dream
> up any sequence that could be used to capture a hash of that password,
> store it, and then use it to compare subsequent attempts?
Usually LOGIN and PLAIN authentication methods are used
(inside or outside STARTTLS). In acl_check_auth
$smtp_command_argument usually contains username and password
(possibly encoded) and can be hashed.
Alternatively, server_condition in authenticators can be used.
But the problem is that real mail clients close SMTP session in case
of rejected password, so neither $acl_m nor $acl_c can be used for storage.
So, the implementation depends on storage: small files in a directory,
a database or memcache. You'll need expiration.
I think that the abovementioned example is enough far-fetched
to not worry about.
Also, there are email notifications of blocked IP-addresses.
Also, you can whitelist your IP-addresses. If several your users
are behind the same NAT then the IP-address is likely your company's.
