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

Stefan Miklosovic commented on CASSANDRA-16669:
-----------------------------------------------

Hi [~sumanth.pasupuleti],

thanks for the patch.

1) Are you aware of ecaudit from Ericsson? They did this obfuscation very 
robustly, treating new lines, obfuscating just passwords and so on. I do not 
think we should be inspired by what PG audit does when there is obviously more 
appropriate solution already existing. Check this (1) and (2). We can nicely 
obfuscate just passwords leaving other parts untouched.

(1) https://github.com/Ericsson/ecaudit/issues/170

(2) 
[https://github.com/emolsson/ecaudit/blob/f01e3c1f75a9df2d767abc051b5b224d9b6c66f9/ecaudit/src/main/java/com/ericsson/bss/cassandra/ecaudit/obfuscator/PasswordObfuscator.java]

2) Do you think that we would ever have a need to see these passwords _not_ 
obfuscated? What is the use case? Why would we want to see them in plaintext? I 
am not sure we ever need this, even it is configurable. I just do not see the 
reason for that configuration option to exist. It would also simplify the code.

 

> Password obfuscation for DCL audit log statements
> -------------------------------------------------
>
>                 Key: CASSANDRA-16669
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-16669
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: Tool/auditlogging
>            Reporter: Vinay Chella
>            Assignee: Sumanth Pasupuleti
>            Priority: Normal
>              Labels: audit, security
>          Time Spent: 10m
>  Remaining Estimate: 0h
>
> The goal of this JIRA is to obfuscate passwords or any sensitive information 
> from DCL audit log statements.
> Currently, (Cassandra version 4.0-rc1) logs query statements for any DCL 
> ([ROLE|https://cassandra.apache.org/doc/latest/cql/security.html#database-roles]
>  and [USER|https://cassandra.apache.org/doc/latest/cql/security.html#users] ) 
> queries with passwords in plaintext format in audit log files.
> The current workaround to avoid plain text passwords from being logged in 
> audit log files is either by 
> [excluding|https://cassandra.apache.org/doc/latest/operating/audit_logging.html#options]
>  DCL statements from auditing or by excluding the user who is creating these 
> roles from auditing.
> It would be ideal for Cassandra to provide an option or default to obfuscate 
> passwords or any sensitive information from DCL audit log statements.
> Sample audit logs with DCL queries
> {code:sh}
> Type: audit
> LogMessage: 
> user:cassandra|host:localhost/127.0.0.1:7000|source:/127.0.0.1|port:51908|timestamp:1620190499676|type:CREATE_ROLE|category:DCL|operation:CREATE
>  ROLE new_role;
> Type: audit
> LogMessage: 
> user:cassandra|host:localhost/127.0.0.1:7000|source:/127.0.0.1|port:51908|timestamp:1620190505313|type:CREATE_ROLE|category:DCL|operation:CREATE
>  ROLE alice WITH PASSWORD = 'password_a' AND LOGIN = true;
> Type: audit
> LogMessage: 
> user:cassandra|host:localhost/127.0.0.1:7000|source:/127.0.0.1|port:51908|timestamp:1620190519521|type:REQUEST_FAILURE|category:ERROR|operation:ALTER
>  ROLE bob WITH PASSWORD = 'PASSWORD_B' AND SUPERUSER = false;; bob doesn't 
> exist
> Type: audit
> LogMessage: 
> user:cassandra|host:localhost/127.0.0.1:7000|source:/127.0.0.1|port:51908|timestamp:1620190525376|type:CREATE_ROLE|category:DCL|operation:CREATE
>  ROLE bob WITH PASSWORD = 'password_b' AND LOGIN = true AND SUPERUSER = true;
> Type: audit
> LogMessage: 
> user:cassandra|host:localhost/127.0.0.1:7000|source:/127.0.0.1|port:51908|timestamp:1620190532462|type:ALTER_ROLE|category:DCL|operation:ALTER
>  ROLE bob WITH PASSWORD = 'PASSWORD_B' AND SUPERUSER = false;
> {code}
> It is also ideal to document this workaround or assumption in Cassandra audit 
> log documentation until we close this JIRA



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to