[
https://issues.apache.org/jira/browse/CASSANDRA-17334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17493254#comment-17493254
]
Berenguer Blasi edited comment on CASSANDRA-17334 at 2/16/22, 2:44 PM:
-----------------------------------------------------------------------
Hi [~Bowen Song] ,
first of all thanks for taking the time to look into this. I see your concerns
and I agree but I think we are talking about different things. This is my fault
because I have the context from CASSANDRA-16801and CASSANDRA-16669 in my head I
didn't provide.
I am not referring to the authentication process which iiuc is where your
concerns lie? and I agree with you. If you read a bit on those 2 tickets we had
the problem that we were unintentionally logging plain text passwords when,
i.e., creating a user. That is because the CQL statement itself to create the
user carries the password in plain text, then audit logging would log it. It
could happen the same with some CQL traffic capturing/replay tool i.e.. As the
passwords are embedded into the DCL CQL anything that captures the CQL command
string could leak them because it would be out of our control.
We have the above 2 tickets to mitigate that. As you rightly point out that
data should be removed and we do now. Still that removal happens only at the
places we currently know about and control. We might add other functionality in
the future were we forget to add this protection, people could attach custom
software that captures CQL, create their own private implementation of some
class, forks, etc.
So you're right again saying that leaking a hashed password is not ideal. But
it's better than leaking it in plain text. With this ticket any captured CQL
would now have a hash instead of the password. That would work for current,
future and any work outside of our control (3rd party software, 3rd party code,
forks...)
Does this help and makes sense?
was (Author: bereng):
Hi [~Bowen Song] ,
first of all thanks for taking the time to look into this. I see your concerns
and I agree but I think we are talking about different things. This is my fault
because I have the context from CASSANDRA-16801and CASSANDRA-16669 in my head I
didn't provide.
I am not referring to the authentication process which iiuc is where your
concerns lie? and I agree with you. If you read a bit on those 2 tickets we had
the problem that we were unintentionally logging plain text passwords when,
i.e., creating a user. That is because the CQL statement itself to create the
user carries the password in plain text, then audit logging would log it. It
could happen the same with some CQL traffic capturing/replay tool i.e.. As the
passwords are embedded into the DCL CQL anything that captures the CQL command
string could leak them because it would be out of our control.
We have the above 2 tickets to mitigate that. As you rightly point out that
data should be removed and we do now. Still that removal happens only at the
places we currently know about and control. We might add other functionality in
the future were we forget to add this protection, people could attach custom
software that captures CQL, create their own private implementation of some
class, etc.
So you're right again saying that leaking a hashed password is not ideal. But
it's better than leaking it in plain text. with this ticket any captured CQL
would now have a hash instead of the password. That would work for current,
future and any work outside of our control (3rd party software or 3rd party
code)
Does this help and makes sense?
> 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: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
