[
https://issues.apache.org/jira/browse/CASSANDRA-19734?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17861284#comment-17861284
]
Francisco Guerrero commented on CASSANDRA-19734:
------------------------------------------------
[~smiklosovic] I'd recommend hooking a new
{{org.apache.cassandra.auth.AuthEvents.Listener}} to
{{org.apache.cassandra.auth.AuthEvents}}. You'll have access to the failure
context there. For the username concern that [~bbotella] is bringing up, it is
worth noting that Mutual TLS connections will not have a username, and we'd
still want to block malicious requests that are coming with some certificate.
Also, I can think of a malicious actor trying different username/password
combinations, so restricting the blocking to a single username might not
necessarily be a viable solution.
> Rate limiting per-node on failed log-in attempts
> ------------------------------------------------
>
> Key: CASSANDRA-19734
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19734
> Project: Cassandra
> Issue Type: New Feature
> Reporter: Stefan Miklosovic
> Assignee: Stefan Miklosovic
> Priority: Normal
>
> If there is a malicious attacker who is brute-forcing passwords / usernames,
> we should just ban such user for some time. On the other hand, we should
> enable logging in for genuine users who just happened to provide invalid
> passwords for multiple times, we do not want to ban these completely.
> A rate limit might be something like "5 times per a minute".
> This should be based on IP address of a client to identify the attacker. If
> we based this on invalid passwords only, an attacker might just change the
> usernames to bypass that.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
