To me this doesn't sound very useful. Here's a few threat model I can
think of that may be related to this proposal, and why is this not
addressing the issues & what should be done instead.
1. passwords are send over network in plaintext allows passive packet
sniffier to learn about the password
When the user logging in and authenticating themselves, they will have
to send both the username and password to the server in plaintext anyway.
Securing the connection with TLS should address this concern.
2. malicious intermediaries (external loadbancer, middleware, etc.) are
able learn about the password
The admin user must login against the intermediary before
creating/altering other users, this exposes the admin user's credentials
to the malicious intermediary.
Only use trusted intermediaries, and use TLS between the client &
Cassandra server wherever possible (e.g. don't terminate TLS at the
loadbalancer).
3. accidentally logging the password to an insecure log file
Logging a hashed password to an insecure log file is still very bad
The logger module should correctly redact the data
If this proposal helps mitigating a different threat model that you have
in mind, please kindly share it with us.
On 16/02/2022 07:44, Berenguer Blasi wrote:
Hi all,
I would like to propose to add support for client password hashing
(https://issues.apache.org/jira/browse/CASSANDRA-17334). If anybody
has any concerns or question with this functionality I will be happy
to discuss them.
Thx in advance.
