[ https://issues.apache.org/jira/browse/CASSANDRA-17334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17493912#comment-17493912 ]
Bowen Song edited comment on CASSANDRA-17334 at 2/17/22, 12:33 PM: ------------------------------------------------------------------- Hello [~bereng] , Moving the plaintext password from CQL to somewhere else doesn't fix the problem of accidental logging of password, it only moves the problem elsewhere, because a plaintext password must be supplied to the tool instead. Imaging user made a typo in the command line when invoking the tool, but kept going and typed in the password and pressed ENTER, what's going to happen? The plaintext password will almost certainly show up in the bash history (or whatever shell they use). If the password must be hashed outside the CQL statement, at least use a pseudo CQLSH command (the likes of HELP and COPY already exists in CQLSH) to do the job instead of an external tool shipped with the Cassandra *server* software. Because in most common use cases a user would not have shell access to the Cassandra server, and they won't have easy access to a tool that's only shipped with the server software. The users, however, would usually have access to the client side tools, such as CQLSH. There's no overhead of parsing CQL statement if a pseudo command is used, and the tool is aware of the server version and can produce the hash in the most suitable algorithm for the server version. Since pseudo command doesn't end with semicolon, the chance of accidentally send the password to the server is much smaller. The user can always Ctrl-C out of it if they accidentally made a typo in the pseudo command itself and the "..." prompt shows up. On the topic of MySQL, all the DBAs I know uses plaintext when dealing with passwords, the auth_string thing may sound nice, but nobody I know actually uses it. It's just much harder to use by design, and human nature means we would always prefer the easier path for the same goal. To prevent human mistakes, such as typo and spelling error, the best method is automation, not obfuscation. Regardless how this ticket is implemented, please always allow the user to use plaintext password, because this makes automation much easier. was (Author: bowen song): Hello [~bereng] , Moving the plaintext password from CQL to somewhere else doesn't fix the problem of accidental logging of password, it only moves the problem elsewhere, because a plaintext password must be supplied to the tool instead. Imaging user made a typo in the command line when invoking the tool, but kept going and typed in the password and pressed ENTER, what's going to happen? The plaintext password will almost certainly show up in the bash history (or whatever shell they use). If the password must be hashed outside the CQL statement, at least use a pseudo CQLSH command (the likes of HELP and COPY already exists in CQLSH) to do the job instead of an external tool shipped with the Cassandra *server* software. Because in most common use cases a user would not have shell access to the Cassandra server, and they won't have easy access to a tool that's only shipped with the server software. The users, however, would usually have access to the client side tools, such as CQLSH. There's no overhead of parsing CQL statement if a pseudo command is used, and the tool is aware of the server version and can produce the hash in the most suitable algorithm for the server version. Since pseudo command doesn't end with semicolon, the chance of accidentally send the password to the server is much smaller. The user can always Ctrl-C out of it if they accidentally made a typo in the pseudo command itself and the "..." prompt shows up. On the topic of MySQL, all the DBAs I know uses plaintext when dealing with passwords, the auth_string thing may sound nice, but nobody I know actually uses it. It's just much harder to use by design, and human nature means we would always prefer the easier path for the same goal. To prevent human mistakes, such as typo and spelling error, the best method is automation, not obfuscation. Regardless how this ticket is implemented, please always allow the user to use plaintext password, because this makes automation much easier. > 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