[
https://issues.apache.org/jira/browse/CASSANDRA-19817?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17871778#comment-17871778
]
Stefan Miklosovic commented on CASSANDRA-19817:
-----------------------------------------------
Why not to emit this warning to users themselves? Letting the operator know
which has to let know the users seems like one more step. What is your thinking
behind modeling it like that?
> PasswordAuthenticator accepts passwords with matching prefixes exceeding
> bcrypt length limit
> --------------------------------------------------------------------------------------------
>
> Key: CASSANDRA-19817
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19817
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Client
> Reporter: Abe Ratnofsky
> Priority: Normal
>
> Cassandra allows roles to be created with passwords longer than the bcrypt
> length limit of 72 bytes[1]. All passwords sharing a 72-byte prefix have the
> same bcrypt hash, so users can authenticate with passwords that do not
> exactly match a role's configured password.
>
> Users expect authentication to only happen when there is an exact match
> between a role's configured password and the password provided by an agent
> authenticating against that role.
> I have a few elements to propose:
> 1. Cassandra rejects creation of passwords (via CREATE ROLE or ALTER ROLE)
> that exceed the 72-byte limit
> 2. Cassandra logs a server-side warning (not ClientWarn) when a role's
> password exceeds the length limit, recommending a password change, with
> NoSpamLogger
> Thanks to Stefan Miklosovic for investigating this with me.
> As for proof, here's a failing test:
> {code:java}
> import org.mindrot.jbcrypt.BCrypt;
> public class PasswordCollisionTest
> {
> @Test
> public void testLongPassword() throws Exception
>
> { String longpassword =
> "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa";
> String salt = BCrypt.gensalt(); String longhashed =
> BCrypt.hashpw(longpassword, salt);
> Assert.assertTrue(BCrypt.checkpw(longpassword, longhashed)); String
> longerpassword = longpassword + "bbb"; String longerhashed =
> BCrypt.hashpw(longerpassword, salt);
> Assert.assertNotEquals(longerhashed, longhashed); }
> }
> {code}
>
> Here's a similar test as an end-user would experience it, against recent
> trunk (fe30e227bdedf13f890e242d2646598398ba8bed):
> {code:java}
> $ ./bin/cqlsh -u cassandra -p cassandra
> Connected to Test Cluster at 127.0.0.1:9042
> [cqlsh 6.0.0 | Cassandra 5.1-SNAPSHOT | CQL spec 3.4.8 | Native protocol v5]
> Use HELP for help.
> cassandra@cqlsh> CREATE ROLE longpassword WITH PASSWORD =
> 'aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa'
> AND LOGIN = true;
> cassandra@cqlsh> exit;
> $ ./bin/cqlsh -u longpassword -p
> aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
> Connected to Test Cluster at 127.0.0.1:9042
> [cqlsh 6.0.0 | Cassandra 5.1-SNAPSHOT | CQL spec 3.4.8 | Native protocol v5]
> Use HELP for help.
> longpassword@cqlsh> exit;
> $ ./bin/cqlsh -u longpassword -p
> aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaabbb
> Connected to Test Cluster at 127.0.0.1:9042
> [cqlsh 6.0.0 | Cassandra 5.1-SNAPSHOT | CQL spec 3.4.8 | Native protocol v5]
> Use HELP for help.
> longpassword@cqlsh> exit;
> {code}
>
> [1]: [https://en.wikipedia.org/wiki/Bcrypt#Maximum_password_length]
--
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
