You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cassandra.apache.org by Berenguer Blasi <be...@gmail.com> on 2022/02/16 07:44:20 UTC
Client password hashing
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.
Re: Client password hashing
Posted by Berenguer Blasi <be...@gmail.com>.
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.
>>>
Re: Client password hashing
Posted by "J. D. Jordan" <je...@gmail.com>.
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.
>>
Re: Client password hashing
Posted by Bowen Song <bo...@bso.ng>.
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.
>