[ 
https://issues.apache.org/jira/browse/CASSANDRA-19734?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17860911#comment-17860911
 ] 

Stefan Miklosovic commented on CASSANDRA-19734:
-----------------------------------------------

The way it is implemented right now is that we can not obtain a username which 
tried to log in but failed in AuthUtil.

If we do there this
{code:java}
AuthenticatedUser user = negotiator.getAuthenticatedUser();
queryState.getClientState().login(user); {code}
When the first statement fails (because password was not matching) then we do 
not know the user name. Because it is burried in getAuthenticatedUser and never 
returned so we can not act on that - to ban it, it is too late.

We might do it directly in PasswordAuthenticator but that would be just 
"authenticator-specific". Doing it somehow in AuthUtils is 
IAuthenticator-agnostic.

I dont know how to move forward here yet.

There are also implementation complications with OPTIONS etc (to keep it 
aligned with whatever "cache" for banned users we have when role is added / 
removed or node restarted) but we are not there yet.

> 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

Reply via email to