[
https://issues.apache.org/jira/browse/CASSANDRA-17334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17493251#comment-17493251
]
Berenguer Blasi commented on CASSANDRA-17334:
---------------------------------------------
[~Bowen Song] I am moving your message from the ML to here so we keep the ML
clean. I hope this is ok?
{quote}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. {quote}
> Pre hashed passwords in CQL
> ---------------------------
>
> Key: CASSANDRA-17334
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17334
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Authorization
> Reporter: Berenguer Blasi
> Assignee: Berenguer Blasi
> Priority: Normal
> Fix For: 4.1
>
>
> As seen on CASSANDRA-16801 and friends we are working across the system with
> plain text passwords. These can be unintentionally revealed by intermediate
> systems. Allowing the use of hashed passwords should mitigate that. The idea
> is to add a new option {{HASHED PASSWORD}} for {{CREATE/ALTER ROLE/USER}}.
> Examples:
> {noformat}
> CREATE ROLE foo WITH login = true AND hashed password =
> '$2a$10$JSJEMFm6GeaW9XxT5JIheuEtPvat6i7uKbnTcxX3c1wshIIsGyUtG';
> ALTER ROLE foo WITH hashed password =
> '$2a$10$JSJEMFm6GeaW9XxT5JIheuEtPvat6i7uKbnTcxX3c1wshIIsGyUtG';
> {noformat}
> To generate the password hash, there will be a new tool {{hash_password}} in
> resources/cassandra/bin
> Based on original works from [~snazy]
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
