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. >>
