[CASSANDRA-16983] Separating CQLSH credentials from the cqlshrc file

• Type: Improvement
• Status: Resolved
• Priority: Normal
• Resolution: Fixed
• Fix Version/s: 4.1-alpha1, 4.1
• Component/s: Tool/cqlsh
• Labels: lhf
• Change Category: Operability
• Complexity: Low Hanging Fruit
• Platform: All

Source Control Link

https://github.com/apache/cassandra/commit/917d74bd35712f8374ecefd1d890d02916162daa

Test and Documentation Plan

The author has tested the change manually. Automated tests haven't been run.
Documentation has been updated.

• Assignee: Bowen Song
• Reporter: Bowen Song

Authors

Bowen Song

Reviewers

Brandon Williams, Brian Houser, Stefan Miklosovic

• Created: 21/Sep/21 16:02
• Updated: 18/Sep/22 00:52
• Resolved: 11/Oct/21 16:42

Description

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 propose 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)