[
https://issues.apache.org/jira/browse/CASSANDRA-17334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17493912#comment-17493912
]
Bowen Song commented on CASSANDRA-17334:
----------------------------------------
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
