[
https://issues.apache.org/jira/browse/CASSANDRA-17334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17493304#comment-17493304
]
Bowen Song edited comment on CASSANDRA-17334 at 2/16/22, 9:46 PM:
------------------------------------------------------------------
Thanks [~bereng] for the clarification of the reasons behind this proposal.
I believe 3rd party software and tools capturing CQL is not the scope of this
discussion. It's the 3rd party software/tool's responsibility to redact the
sensitive data they capture. That is not limited to the Cassandra
authentication credentials, also the sensitive data stored in user created
tables.
With the 3rd party stuff out of our way, I believe adding tests to ensure
password is never logged by Cassandra is sufficient to prevent password
leakages from existing features. Future newly added features that logs the CQL
statements will of course require new tests to be added, but I don't see this
kind of features has been or will be added frequently.
If, however, the feature must be added, the hash should ideally be done in the
CQLSH and Cassandra client libraries, instead of an external tool. I personally
have a distaste for relying on external tools to do basic stuff. In my opinion,
it only makes sense to introduce an external tool if the functionality is
rarely used and fairly complex or is intended to run independent of the
software itself.
In this particular case, an external password hashing tool is inconvenient to
install & use when the user don't have shell access to the Cassandra server.
The existence of an external tool will make automation dealing with credentials
more complex. The tool can also become a headache if the hash algorithm is
changed in the future, because the tool will then need to know which hash
algorithm to use in order to match the expectation of the Cassandra server.
All the above mentioned issues will go away if the hashing is done in CQLSH or
client libraries, the user can simply write the statement in CQLSH:
CREATE .... WITH hashed password = PASSWORD_HASH('whatever')
or client library:
session.execute("CREATE ... WITH hashed password = ?",
session.passwordHash("whatever"))
and the CQLSH/library handles the password hash locally before sending the
statement to the server. The advantage of this is the automation tool / user /
developers don't need to deal with password hashes, and the CQLSH/library knows
the Cassandra server version and can choose the correct hash algorithm.
was (Author: bowen song):
Thanks [~bereng] for the clarification of the reasons behind this proposal.
I believe 3rd party software and tools capturing CQL is not the scope of this
discussion. It's the 3rd party software/tool's responsibility to redact the
sensitive data they capture. That is not limited to the Cassandra
authentication credentials, also the sensitive data stored in user created
tables.
With the 3rd party stuff out of our way, I believe adding tests to ensure
password is never logged by Cassandra is sufficient to prevent password
leakages from existing features. Future newly added features that logs the CQL
statements will of course require new tests to be added, but I don't see this
kind of features has been or will be added frequently.
If, however, the feature must be added, the hash should ideally be done in the
CQLSH and Cassandra client libraries, instead of an external tool. I personally
have a distaste for relying on external tools to do basic stuff. In my opinion,
it only makes sense to introduce an external tool if the functionality is
rarely used and fairly complex or is intended to run independent of the
software itself.
In this particular case, an external password hashing tool is incontinent to
install & use when the user don't have shell access to the Cassandra server.
The existence of an external tool will make automation dealing with credentials
more complex. The tool can also become a headache if the hash algorithm is
changed in the future, because the tool will then need to know which hash
algorithm to use in order to match the expectation of the Cassandra server.
All the above mentioned issues will go away if the hashing is done in CQLSH or
client libraries, the user can simply write the statement in CQLSH:
CREATE .... WITH hashed password = PASSWORD_HASH('whatever')
or client library:
session.execute("CREATE ... WITH hashed password = ?",
session.passwordHash("whatever"))
and the CQLSH/library handles the password hash locally before sending the
statement to the server. The advantage of this is the automation tool / user /
developers don't need to deal with password hashes, and the CQLSH/library knows
the Cassandra server version and can choose the correct hash algorithm.
> Pre hashed passwords in CQL
> ---------------------------
>
> Key: CASSANDRA-17334
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17334
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Authorization
> Reporter: Berenguer Blasi
> Assignee: Berenguer Blasi
> Priority: Normal
> Fix For: 4.1
>
>
> As seen on CASSANDRA-16801 and friends we are working across the system with
> plain text passwords. These can be unintentionally revealed by intermediate
> systems. Allowing the use of hashed passwords should mitigate that. The idea
> is to add a new option {{HASHED PASSWORD}} for {{CREATE/ALTER ROLE/USER}}.
> Examples:
> {noformat}
> CREATE ROLE foo WITH login = true AND hashed password =
> '$2a$10$JSJEMFm6GeaW9XxT5JIheuEtPvat6i7uKbnTcxX3c1wshIIsGyUtG';
> ALTER ROLE foo WITH hashed password =
> '$2a$10$JSJEMFm6GeaW9XxT5JIheuEtPvat6i7uKbnTcxX3c1wshIIsGyUtG';
> {noformat}
> To generate the password hash, there will be a new tool {{hash_password}} in
> resources/cassandra/bin
> Based on original works from [~snazy]
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
