[
https://issues.apache.org/jira/browse/CASSANDRA-16983?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17420875#comment-17420875
]
Bowen Song edited comment on CASSANDRA-16983 at 9/27/21, 4:27 PM:
------------------------------------------------------------------
Okay, I need some opinions on the following issue.
The 'cqlsh_tests' in dtests doesn't like the newly added insecure password in
command line warning message, and many tests will fail if the warning text is
added without any other actions taken. I can think of 3 different solutions:
1. Add a new undocumented hidden option to 'cqlsh.py' to skip the warning
message when '\-p password' is used. For example
"\-\-insecure-password-without-warning". Then in the dtests, add this parameter
to the command line if the Cassandra version is >= a specific value, such as
'4.1'.
2. Add a new undocumented environment variable to 'cqlsh.py' to skip the
warning message. For example "CQLSH_INSECURE_PASSWORD=1". In dtests, the
environment variable can be set regardless of the version, as the old version
cqlsh will ignore it automatically.
3. Change the dtests to expect the warning message if the Cassandra version is
>= a specific value.
I would like to hear your opinions on the above, what do you think is the best
approach?
was (Author: bowen song):
Okay, I need some opinions on the following issue.
The 'cqlsh_tests' in dtests doesn't like the newly added insecure password in
command line warning message, and many tests will fail if the warning text is
added without any other actions taken. I can think of 3 different solutions:
1. Add a new undocumented hidden option to 'cqlsh.py' to skip the warning
message when '-p password' is used. For example
"--insecure-password-without-warning". Then in the dtests, add this parameter
to the command line if the Cassandra version is >= a specific value, such as
'4.1'.
2. Add a new undocumented environment variable to 'cqlsh.py' to skip the
warning message. For example "CQLSH_INSECURE_PASSWORD=1". In dtests, the
environment variable can be set regardless of the version, as the old version
cqlsh will ignore it automatically.
3. Change the dtests to expect the warning message if the Cassandra version is
>= a specific value.
I would like to hear your opinions on the above, what do you think is the best
approach?
> Separating CQLSH credentials from the cqlshrc file
> --------------------------------------------------
>
> Key: CASSANDRA-16983
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16983
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/cqlsh
> Reporter: Bowen Song
> Assignee: Bowen Song
> Priority: Normal
> Labels: lhf
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Currently, the CQLSH tool accepts credentials (username & password) from the
> following 3 places:
> 1. the command line parameter "-p"
> 2. the cqlshrc file
> 3. prompt the user
> This is not ideal.
> Credentials in the command line is a security risk, because it could be see
> by other users on a shared system.
> The cqlshrc file is better, but still not good enough. Because the cqlshrc
> file is a config file, it's often acceptable to have it as a world readable
> file, and share it with other users. It also prevents user from having
> multiple sets of credentials, either for the same Cassandra cluster or
> different clusters.
> To improve the security of CQLSH and make it secure by design, I purpose the
> following changes:
> * Warn the user if a password is giving in the command line, and recommend
> them to use a credential file instead
> * Warn the user if credentials are present in the cqlshrc file and the
> cqlshrc file is not secure (e.g.: world readable or owned by a different user)
> * Deprecate credentials in the cqlshrc, and recommend the user to move them
> to a separate credential file. The aim is to not break anything at the
> moment, but eventually stop accepting credentials from the cqlshrc file.
> * Reject the credentials file if it's not secure, and tell the user how to
> secure it. Optionally, prompt the user for password if it's an interactive
> session. (Think how does OpenSSH handle insecure credential files)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
