Yeah that sounds great also imo. I'll move Bowen's comment to the ticket
and we can continue there. Thx
On 16/2/22 14:55, J. D. Jordan wrote:
Can we have the discussion on the ticket?
Thanks
-Jeremiah
On Feb 16, 2022, at 6:23 AM, Bowen Song <bo...@bso.ng> wrote:
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.
