[
https://issues.apache.org/jira/browse/CASSANDRA-17334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17493729#comment-17493729
]
Berenguer Blasi edited comment on CASSANDRA-17334 at 2/17/22, 12:15 PM:
------------------------------------------------------------------------
Hi [~Bowen Song] ,
all good points thx!. Yes I agree completely it's 3rd parties responsibility to
remove sensitive information but I also think that if you have the option it's
not there in the first place that's even better. Also it's not always possible
to remove the sensitive information (c16669, c16801). So you go from a position
where passwords _may_ leak to a position where passwords _won't_ leak which is
a win imo.
Regarding the tool, yes, bringing in a new external tool would be a bad idea
+100. What I mean is just creating a script under {{tools/bin}}. That would sit
nicely in the codebase just like the rest of the other scripts in C* :-)
The proposal to have the hashing function embedded in the CQL is very elegant
imo but unfortunately doesn't solve the problem iiuc. If I issue:
{quote}WITH hashed password PASSWORD_HASH('whatever')
{quote}
and that CQL gets logged {{whatever}} will still be logged in plain text. Yes
ideally it should have been removed but tickets 16669 and 16801 are proof that
this is not always possible. Whereas if I issue:
{quote}WITH hashed password
'$2a$10$JSJEMFm6GeaW9XxT5JIheuEtPvat6i7uKbnTcxX3c1wshIIsGyUtG'
{quote}
Then you don't have the plain text password anywhere. Notice the password
removal or in CQL hashing problems apply regardless you're on client or server
side. As example think of a statement carrying a plain text password that
doesn't parse for whatever reason. Also that would imply having all the CQL
parsing on the client we don't have which would be an herculean effort, if
possible at all. Also think this will be an optional feature, nobody is going
to be forced into it.
I know I am very bad at explaining things lol so maybe reading the docs of this
feature in some of the other major DBs, where most have it, helps us. I.e.
[here|https://dev.mysql.com/doc/refman/8.0/en/create-user.html] you can read
the first paragraph shaded in blue and titled 'important' and how later on the
option {{AS 'auth_string'}} allows to provide the hashed string directly. It's
an interesting subject, lots of good reading on this issue around. Hope it
makes sense?
was (Author: bereng):
Hi [~Bowen Song] ,
all good points thx!. Yes I agree completely it's 3rd parties responsibility to
remove sensitive information but I also think that if you have the option it's
not there in the first place that's even better. Also it's not always possible
to remove the sensitive information (c16669, c16801). So you go from a position
where passwords _may_ leak to a position where passwords _won't_ leak which is
a win imo.
Regarding the tool, yes, bringing in a new external tool would be a bad idea
+100. What I mean is just creating a script under {{tools/bin}}. That would sit
nicely in the codebase just like the rest of the other scripts in C* :-)
The proposal to have the hashing function embedded in the CQL is very elegant
imo but unfortunately doesn't solve the problem iiuc. If I issue:
{quote}WITH hashed password PASSWORD_HASH('whatever')
{quote}
and that CQL gets logged {{whatever}} will still be logged in plain text. Yes
ideally it should have been removed but tickets 16669 and 16801 are proof that
this is not always possible. Whereas if I issue:
{quote}WITH hashed password
'$2a$10$JSJEMFm6GeaW9XxT5JIheuEtPvat6i7uKbnTcxX3c1wshIIsGyUtG'
{quote}
Then you don't have the plain text password anywhere. Notice the password
removal or in CQL hashing problems apply regardless you're on client or server
side. As example think of a statement carrying a plain text password that
doesn't parse for whatever reason. Also that would imply having all the CQL
parsing on the client we don't have which would be an herculean effort, if
possible at all.
I know I am very bad at explaining things lol so maybe reading the docs of this
feature in some of the other major DBs, where most have it, helps us. I.e.
[here|https://dev.mysql.com/doc/refman/8.0/en/create-user.html] you can read
the first paragraph shaded in blue and titled 'important' and how later on the
option {{AS 'auth_string'}} allows to provide the hashed string directly. It's
an interesting subject, lots of good reading on this issue around. Hope it
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
