RFC 6186 is being mentioned in discussions about 4409bis, but I don't think
this belongs to yam@ nor ietf@ lists. So I try here.
On 16.08.2011 23:01, Martin Rex wrote on ietf(_at_)ietf(_dot_)org:
Security-wise, the SRV record suggested by rfc6186 seems to create
additional security problems, so I would also not like to see it being
"adopted" as is. :-/
As well as they automate client setup, SRV records also automate cracking.
IMHO, this issue should be fixed in SMTP AUTH. The Security Considerations
in RFC 4954 say that
Servers MAY implement a policy whereby the connection is dropped
after a number of failed authentication attempts. If they do so,
they SHOULD NOT drop the connection until at least 3 attempts to
authenticate have failed.
I don't think that suffices. What might the replacement text for an errata
suggest instead?
Users of fail2ban probably also drop any further connection attempt from the
relevant IP address(es) for at least some minutes. This still doesn't
prevent distributed attacks.
Forcing passwords changes annoys users, if it is frequent enough.
The most reasonable thing I can think of is the capability of "blocking" an
account when a number of failures becomes comparable with the entropy of the
current password, wherever they came from. I mean, if a clever user chooses
a password with 24 bits of entropy, her account should be blocked sometimes
after, say, 16384 failed attempts --2^24/1024, about a thousandth of the
search space, see http://en.wikipedia.org/wiki/Password_strength
There are two difficulties with this approach:
1) "Blocking" implies being able to reach users in some other way.
2) Servers tend to be sparing in their logging failed login attempts. They
obviously do so for security reasons... How do we tackle this catch-22?
TIA for any reply