[ 
https://issues.apache.org/jira/browse/CASSANDRA-19765?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17865407#comment-17865407
 ] 

Stefan Miklosovic edited comment on CASSANDRA-19765 at 7/12/24 10:25 AM:
-------------------------------------------------------------------------

Would not it be better if this was treated not on SELECT level but directly 
when we are executing "GRANT SELECT ON system_auth.roles TO nonsuperuser;"? Why 
not to reject this upon granting rather than checking this on every select?

Does it related to this: "but permission-tightening across the entire resource 
hierarchy is complicated and blocking access to just this column is fairly 
simple."?

If so, what is complicated about that? Can you elaborate? By this approach it 
seems like we are plumbing it _after it happened_, we are not preventing it 
from happening.


was (Author: smiklosovic):
Would not it be better if this was treated not on SELECT level but directly 
when we are executing "GRANT SELECT ON system_auth.roles TO nonsuperuser;"? Why 
not to reject this upon granting rather than checking this on every select?

> Remove accessibility to system_auth.roles salted_hash for non-superusers
> ------------------------------------------------------------------------
>
>                 Key: CASSANDRA-19765
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-19765
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: Legacy/Core
>            Reporter: Abe Ratnofsky
>            Assignee: Abe Ratnofsky
>            Priority: Normal
>             Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 5.0.x
>
>
> Cassandra permits all users with SELECT on system_auth.roles to access 
> contents of the salted_hash column. This column contains a bcrypt hash, which 
> shouldn't be visible. This isn't a significant security risk at the current 
> time, but is prone to [retrospective 
> decryption|https://en.wikipedia.org/wiki/Harvest_now,_decrypt_later]. We 
> should protect this column so passwords cannot be cracked in the future.
>  
>  
> {code:java}
> $ ./bin/cqlsh -u cassandra -p cassandra
> [cqlsh 6.3.0 | Cassandra 5.1-SNAPSHOT | CQL spec 3.4.8 | Native protocol v5] 
> cassandra@cqlsh> CREATE ROLE nonsuperuser WITH LOGIN=true AND 
> PASSWORD='nonsuperuser';
> cassandra@cqlsh> GRANT SELECT ON system_auth.roles TO nonsuperuser;
> cassandra@cqlsh> exit;
> $ ./bin/cqlsh -u nonsuperuser -p nonsuperuser
> [cqlsh 6.3.0 | Cassandra 5.1-SNAPSHOT | CQL spec 3.4.8 | Native protocol v5] 
> nonsuperuser@cqlsh> SELECT * FROM system_auth.roles;
>  role         | can_login | is_superuser | member_of | salted_hash
> --------------+-----------+--------------+-----------+--------------------------------------------------------------
>     cassandra |      True |         True |      null | 
> $2a$10$WMg9UlR7F8Ko7LZxEyg0Ue12BoHR/Dn/0/3YtV4nRYCPcY7/5OmA6
>  nonsuperuser |      True |        False |      null | 
> $2a$10$HmHwVZRk8F904UUNMiUYi.xkVglWyKNgHMo1xJsCCKirwyb9NO/im
> (2 rows)
> {code}
>  
> Patches available:
> 3.0: 
> https://github.com/apache/cassandra/compare/trunk...aratno:cassandra:CASSANDRA-19765-salted_hash-visibility-30
> 3.11: 
> https://github.com/apache/cassandra/compare/trunk...aratno:cassandra:CASSANDRA-19765-salted_hash-visibility-311
> 4.0: 
> https://github.com/apache/cassandra/compare/trunk...aratno:cassandra:CASSANDRA-19765-salted_hash-visibility-40
> 4.1: 
> https://github.com/apache/cassandra/compare/trunk...aratno:cassandra:CASSANDRA-19765-salted_hash-visibility-41
> 5.0: 
> https://github.com/apache/cassandra/compare/trunk...aratno:cassandra:CASSANDRA-19765-salted_hash-visibility-50
> trunk: 
> https://github.com/apache/cassandra/compare/trunk...aratno:cassandra:CASSANDRA-19765-salted_hash-visibility-trunk



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

Reply via email to