[ 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