You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cassandra.apache.org by Stefan Miklosovic <st...@instaclustr.com> on 2021/06/03 20:24:04 UTC
Obfuscation of passwords in audit loging, in or not in 4.0?
Hi list,
During our evaluation of 4.0 internally, we noticed that there are
passwords in the plaintext in audit logging (and in fql). While I was
going through CASSANDRA-12151, I noticed that the password obfuscation
in these components was planned but it was never implemented and it
was merged without it, probably it was just lost in the process.
There is ongoing effort in CASSANDRA-16669 to fix this and we are
almost there, it is a rather easy fix, but the question is: what is
this actually supposed to be merged into?
While I humbly think this is 4.0-worthy, the process we have, as far
as I know, is that there should be only critical fixes in 4.0 so I
guess this will go to 4.0.1, right? Or does this qualify to go to 4.0
still? Where is that line?
The existing workaround is to exclude DCL statements from auditing but
in practice I can imagine that people notice this and exclude it
after they have already been leaked because they do not know in
advance it is not obfuscated.
Are we all on the same page this should go to 4.0.x? I made my peace
with it, I just want to double check that people are aware of this and
4.0 will by default display passwords in audit logs in plain text
otherwise.
One sub-question - do you think that FQL should _not_ obfuscate it? As
it is meant to replay it all, replaying obfuscated passwords does not
make a lot of sense but on the other hand I am not sure we want to
have them in the logs. What is your idea around this?
Regards
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
For additional commands, e-mail: dev-help@cassandra.apache.org
Re: Obfuscation of passwords in audit loging, in or not in 4.0?
Posted by Jeff Jirsa <jj...@gmail.com>.
I am on the side of "this sounds like a really bad bug" for the audit
pieces, maybe less so than FQL. Anyone using audit for real probably has
meaningful audit requirements, which means they're in an industry where
they get audited for security, which means logging passwords is a big deal.
On Thu, Jun 3, 2021 at 3:52 PM benedict@apache.org <be...@apache.org>
wrote:
> I think it can be argued that this is a pretty serious bug for a newly
> introduced feature, and qualifies for inclusion in an RC, but I don’t
> personally have a strong opinion on if this should happen.
>
> I can’t imagine how this would be an _exception_ for inclusion in 4.0.1
> though.
>
> From: Mick Semb Wever <mc...@apache.org>
> Date: Thursday, 3 June 2021 at 22:45
> To: dev@cassandra.apache.org <de...@cassandra.apache.org>
> Subject: Re: Obfuscation of passwords in audit loging, in or not in 4.0?
> Thanks for raising this Stefan.
>
>
>
> > While I humbly think this is 4.0-worthy, the process we have, as far
> > as I know, is that there should be only critical fixes in 4.0 so I
> > guess this will go to 4.0.1, right? Or does this qualify to go to 4.0
> > still?
> >
>
>
> I believe the question here is whether this patch is worthy of an exception
> to go to 4.0.x. (i.e. 4.0.1)
> At this point in time all improvements would be by default slated for 4.x
> (i.e. 4.1)
>
> It does not qualify as a RC critical bug for 4.0.0.
>
> Looking at the patch it is simple, and one could almost consider it a
> security fix on a new 4.0 feature, so I'd say it's a valid exception for
> 4.0.x.
> Keen to hear what others think. And how we should go about requesting such
> exceptions for non-bugs during each annual release cycle.
>
Re: Obfuscation of passwords in audit loging, in or not in 4.0?
Posted by Benjamin Lerer <bl...@apache.org>.
>
> I don't think it ever makes sense to log a password in plaintext, so
> my feeling is we should obfuscate there as well.
+1
Le ven. 4 juin 2021 à 22:06, Brandon Williams <dr...@gmail.com> a écrit :
> On Fri, Jun 4, 2021 at 10:32 AM Stefan Miklosovic
> <st...@instaclustr.com> wrote:
> > I would re-iterate on FQL logging though. What is our decision? Should
> > these passwords be clearly visible or we should obfuscate them too?
>
> I don't think it ever makes sense to log a password in plaintext, so
> my feeling is we should obfuscate there as well.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> For additional commands, e-mail: dev-help@cassandra.apache.org
>
>
Re: Obfuscation of passwords in audit loging, in or not in 4.0?
Posted by Brandon Williams <dr...@gmail.com>.
On Fri, Jun 4, 2021 at 10:32 AM Stefan Miklosovic
<st...@instaclustr.com> wrote:
> I would re-iterate on FQL logging though. What is our decision? Should
> these passwords be clearly visible or we should obfuscate them too?
I don't think it ever makes sense to log a password in plaintext, so
my feeling is we should obfuscate there as well.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
For additional commands, e-mail: dev-help@cassandra.apache.org
Re: Obfuscation of passwords in audit loging, in or not in 4.0?
Posted by Stefan Miklosovic <st...@instaclustr.com>.
Hi,
ok, so this will make it to 4.0 then.
I would re-iterate on FQL logging though. What is our decision? Should
these passwords be clearly visible or we should obfuscate them too?
I am trying to close all remaining questions, while I do get that
passwords in audit are for sure problematic, I do not think that I
have a clear agreement what we should do with FQL yet.
Thank you
On Fri, 4 Jun 2021 at 15:22, Ekaterina Dimitrova <e....@gmail.com> wrote:
>
> +1, please, reclassify it as a bug.
> Thank you Stefan
>
> On Fri, 4 Jun 2021 at 9:13, Brandon Williams <dr...@gmail.com> wrote:
>
> > On Fri, Jun 4, 2021 at 4:32 AM Sam Tunnicliffe <sa...@beobal.com> wrote:
> > > Shipping a brand new, non-experimental feature with a security hole like
> > this feels
> > > counter to our goal of releases being prod ready in .0, so I'm +1 on
> > including it in
> > > an rc/ga
> >
> > I think I have to agree here. We can ship a complete feature, we can
> > remove it and not ship it, but what is not acceptable is shipping it
> > in a broken and potentially dangerous state.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> > For additional commands, e-mail: dev-help@cassandra.apache.org
> >
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
For additional commands, e-mail: dev-help@cassandra.apache.org
Re: Obfuscation of passwords in audit loging, in or not in 4.0?
Posted by Ekaterina Dimitrova <e....@gmail.com>.
+1, please, reclassify it as a bug.
Thank you Stefan
On Fri, 4 Jun 2021 at 9:13, Brandon Williams <dr...@gmail.com> wrote:
> On Fri, Jun 4, 2021 at 4:32 AM Sam Tunnicliffe <sa...@beobal.com> wrote:
> > Shipping a brand new, non-experimental feature with a security hole like
> this feels
> > counter to our goal of releases being prod ready in .0, so I'm +1 on
> including it in
> > an rc/ga
>
> I think I have to agree here. We can ship a complete feature, we can
> remove it and not ship it, but what is not acceptable is shipping it
> in a broken and potentially dangerous state.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> For additional commands, e-mail: dev-help@cassandra.apache.org
>
>
Re: Obfuscation of passwords in audit loging, in or not in 4.0?
Posted by Brandon Williams <dr...@gmail.com>.
On Fri, Jun 4, 2021 at 4:32 AM Sam Tunnicliffe <sa...@beobal.com> wrote:
> Shipping a brand new, non-experimental feature with a security hole like this feels
> counter to our goal of releases being prod ready in .0, so I'm +1 on including it in
> an rc/ga
I think I have to agree here. We can ship a complete feature, we can
remove it and not ship it, but what is not acceptable is shipping it
in a broken and potentially dangerous state.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
For additional commands, e-mail: dev-help@cassandra.apache.org
Re: Obfuscation of passwords in audit loging, in or not in 4.0?
Posted by Sam Tunnicliffe <sa...@beobal.com>.
> On 4 Jun 2021, at 03:44, Jonathan Koppenhofer <jo...@koppedomain.com> wrote:
>
> +1 to this being a serious bug. As a large user, if we used internal
> passwords, this would completely prevent me from using Cassandra native
> audit log capabilities. Disabling DCL is not a great option, as DCL is
> probably the most needed auditable event.
>
> If this is on by default (not sure of default settings) I also assume this
> would be classified as an immediate CVE... Right?
+1, I would think so too.
Shipping a brand new, non-experimental feature with a security hole like this feels
counter to our goal of releases being prod ready in .0, so I'm +1 on including it in
an rc/ga
> I don't directly
> contribute, so I can't talk too much, but I can't see how 4.0.0 could go GA
> with this.
>
>
> On Thu, Jun 3, 2021, 7:24 PM Sumanth Pasupuleti <
> sumanth.pasupuleti.is@gmail.com> wrote:
>
>>> I am on the side of "this sounds like a really bad bug" for the audit
>> pieces, maybe less so than FQL. Anyone using audit for real probably has
>> meaningful audit requirements, which means they're in an industry where
>> they get audited for security, which means logging passwords is a big deal.
>>
>> +1. Given we are shipping audit logging feature for the first time with
>> 4.0, it would be great if this rather low complex patch can be included in
>> the 4.0 RC and thereby ship a "complete feature".
>>
>> On Thu, Jun 3, 2021 at 4:04 PM Vinay Chella <vc...@netflix.com.invalid>
>> wrote:
>>
>>>> I think it can be argued that this is a pretty serious bug for a newly
>>> introduced feature, and qualifies for inclusion in an RC, but I don’t
>>> personally have a strong opinion on if this should happen.
>>> +1
>>>
>>>> One more point - if we keep the workaround, that should be documented
>>> with
>>>> big red letters for the users.
>>>
>>> Yes, heavy +1, if we are not merging it. Another idea, if we are not
>>> merging this in, is to put DCL(CREATE ROLE/USER, ALTER ROLE/USER etc.,)
>>> queries in the default configuration (cassandra.yaml) exclude list to
>> avoid
>>> oops for operators, since that is the only query type that log passwords
>> in
>>> plain text and all other places they are not.
>>>
>>>
>>> Thanks,
>>> Vinay
>>>
>>>
>>> On Thu, Jun 3, 2021 at 3:58 PM benedict@apache.org <be...@apache.org>
>>> wrote:
>>>
>>>> I think it can be argued that this is a pretty serious bug for a newly
>>>> introduced feature, and qualifies for inclusion in an RC, but I don’t
>>>> personally have a strong opinion on if this should happen.
>>>>
>>>> I can’t imagine how this would be an _exception_ for inclusion in 4.0.1
>>>> though.
>>>>
>>>> From: Mick Semb Wever <mc...@apache.org>
>>>> Date: Thursday, 3 June 2021 at 22:45
>>>> To: dev@cassandra.apache.org <de...@cassandra.apache.org>
>>>> Subject: Re: Obfuscation of passwords in audit loging, in or not in
>> 4.0?
>>>> Thanks for raising this Stefan.
>>>>
>>>>
>>>>
>>>>> While I humbly think this is 4.0-worthy, the process we have, as far
>>>>> as I know, is that there should be only critical fixes in 4.0 so I
>>>>> guess this will go to 4.0.1, right? Or does this qualify to go to 4.0
>>>>> still?
>>>>>
>>>>
>>>>
>>>> I believe the question here is whether this patch is worthy of an
>>> exception
>>>> to go to 4.0.x. (i.e. 4.0.1)
>>>> At this point in time all improvements would be by default slated for
>> 4.x
>>>> (i.e. 4.1)
>>>>
>>>> It does not qualify as a RC critical bug for 4.0.0.
>>>>
>>>> Looking at the patch it is simple, and one could almost consider it a
>>>> security fix on a new 4.0 feature, so I'd say it's a valid exception
>> for
>>>> 4.0.x.
>>>> Keen to hear what others think. And how we should go about requesting
>>> such
>>>> exceptions for non-bugs during each annual release cycle.
>>>>
>>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
For additional commands, e-mail: dev-help@cassandra.apache.org
Re: Obfuscation of passwords in audit loging, in or not in 4.0?
Posted by Jonathan Koppenhofer <jo...@koppedomain.com>.
+1 to this being a serious bug. As a large user, if we used internal
passwords, this would completely prevent me from using Cassandra native
audit log capabilities. Disabling DCL is not a great option, as DCL is
probably the most needed auditable event.
If this is on by default (not sure of default settings) I also assume this
would be classified as an immediate CVE... Right? I don't directly
contribute, so I can't talk too much, but I can't see how 4.0.0 could go GA
with this.
On Thu, Jun 3, 2021, 7:24 PM Sumanth Pasupuleti <
sumanth.pasupuleti.is@gmail.com> wrote:
> > I am on the side of "this sounds like a really bad bug" for the audit
> pieces, maybe less so than FQL. Anyone using audit for real probably has
> meaningful audit requirements, which means they're in an industry where
> they get audited for security, which means logging passwords is a big deal.
>
> +1. Given we are shipping audit logging feature for the first time with
> 4.0, it would be great if this rather low complex patch can be included in
> the 4.0 RC and thereby ship a "complete feature".
>
> On Thu, Jun 3, 2021 at 4:04 PM Vinay Chella <vc...@netflix.com.invalid>
> wrote:
>
> > > I think it can be argued that this is a pretty serious bug for a newly
> > introduced feature, and qualifies for inclusion in an RC, but I don’t
> > personally have a strong opinion on if this should happen.
> > +1
> >
> > > One more point - if we keep the workaround, that should be documented
> > with
> > > big red letters for the users.
> >
> > Yes, heavy +1, if we are not merging it. Another idea, if we are not
> > merging this in, is to put DCL(CREATE ROLE/USER, ALTER ROLE/USER etc.,)
> > queries in the default configuration (cassandra.yaml) exclude list to
> avoid
> > oops for operators, since that is the only query type that log passwords
> in
> > plain text and all other places they are not.
> >
> >
> > Thanks,
> > Vinay
> >
> >
> > On Thu, Jun 3, 2021 at 3:58 PM benedict@apache.org <be...@apache.org>
> > wrote:
> >
> > > I think it can be argued that this is a pretty serious bug for a newly
> > > introduced feature, and qualifies for inclusion in an RC, but I don’t
> > > personally have a strong opinion on if this should happen.
> > >
> > > I can’t imagine how this would be an _exception_ for inclusion in 4.0.1
> > > though.
> > >
> > > From: Mick Semb Wever <mc...@apache.org>
> > > Date: Thursday, 3 June 2021 at 22:45
> > > To: dev@cassandra.apache.org <de...@cassandra.apache.org>
> > > Subject: Re: Obfuscation of passwords in audit loging, in or not in
> 4.0?
> > > Thanks for raising this Stefan.
> > >
> > >
> > >
> > > > While I humbly think this is 4.0-worthy, the process we have, as far
> > > > as I know, is that there should be only critical fixes in 4.0 so I
> > > > guess this will go to 4.0.1, right? Or does this qualify to go to 4.0
> > > > still?
> > > >
> > >
> > >
> > > I believe the question here is whether this patch is worthy of an
> > exception
> > > to go to 4.0.x. (i.e. 4.0.1)
> > > At this point in time all improvements would be by default slated for
> 4.x
> > > (i.e. 4.1)
> > >
> > > It does not qualify as a RC critical bug for 4.0.0.
> > >
> > > Looking at the patch it is simple, and one could almost consider it a
> > > security fix on a new 4.0 feature, so I'd say it's a valid exception
> for
> > > 4.0.x.
> > > Keen to hear what others think. And how we should go about requesting
> > such
> > > exceptions for non-bugs during each annual release cycle.
> > >
> >
>
Re: Obfuscation of passwords in audit loging, in or not in 4.0?
Posted by Sumanth Pasupuleti <su...@gmail.com>.
> I am on the side of "this sounds like a really bad bug" for the audit
pieces, maybe less so than FQL. Anyone using audit for real probably has
meaningful audit requirements, which means they're in an industry where
they get audited for security, which means logging passwords is a big deal.
+1. Given we are shipping audit logging feature for the first time with
4.0, it would be great if this rather low complex patch can be included in
the 4.0 RC and thereby ship a "complete feature".
On Thu, Jun 3, 2021 at 4:04 PM Vinay Chella <vc...@netflix.com.invalid>
wrote:
> > I think it can be argued that this is a pretty serious bug for a newly
> introduced feature, and qualifies for inclusion in an RC, but I don’t
> personally have a strong opinion on if this should happen.
> +1
>
> > One more point - if we keep the workaround, that should be documented
> with
> > big red letters for the users.
>
> Yes, heavy +1, if we are not merging it. Another idea, if we are not
> merging this in, is to put DCL(CREATE ROLE/USER, ALTER ROLE/USER etc.,)
> queries in the default configuration (cassandra.yaml) exclude list to avoid
> oops for operators, since that is the only query type that log passwords in
> plain text and all other places they are not.
>
>
> Thanks,
> Vinay
>
>
> On Thu, Jun 3, 2021 at 3:58 PM benedict@apache.org <be...@apache.org>
> wrote:
>
> > I think it can be argued that this is a pretty serious bug for a newly
> > introduced feature, and qualifies for inclusion in an RC, but I don’t
> > personally have a strong opinion on if this should happen.
> >
> > I can’t imagine how this would be an _exception_ for inclusion in 4.0.1
> > though.
> >
> > From: Mick Semb Wever <mc...@apache.org>
> > Date: Thursday, 3 June 2021 at 22:45
> > To: dev@cassandra.apache.org <de...@cassandra.apache.org>
> > Subject: Re: Obfuscation of passwords in audit loging, in or not in 4.0?
> > Thanks for raising this Stefan.
> >
> >
> >
> > > While I humbly think this is 4.0-worthy, the process we have, as far
> > > as I know, is that there should be only critical fixes in 4.0 so I
> > > guess this will go to 4.0.1, right? Or does this qualify to go to 4.0
> > > still?
> > >
> >
> >
> > I believe the question here is whether this patch is worthy of an
> exception
> > to go to 4.0.x. (i.e. 4.0.1)
> > At this point in time all improvements would be by default slated for 4.x
> > (i.e. 4.1)
> >
> > It does not qualify as a RC critical bug for 4.0.0.
> >
> > Looking at the patch it is simple, and one could almost consider it a
> > security fix on a new 4.0 feature, so I'd say it's a valid exception for
> > 4.0.x.
> > Keen to hear what others think. And how we should go about requesting
> such
> > exceptions for non-bugs during each annual release cycle.
> >
>
Re: Obfuscation of passwords in audit loging, in or not in 4.0?
Posted by Vinay Chella <vc...@netflix.com.INVALID>.
> I think it can be argued that this is a pretty serious bug for a newly
introduced feature, and qualifies for inclusion in an RC, but I don’t
personally have a strong opinion on if this should happen.
+1
> One more point - if we keep the workaround, that should be documented with
> big red letters for the users.
Yes, heavy +1, if we are not merging it. Another idea, if we are not
merging this in, is to put DCL(CREATE ROLE/USER, ALTER ROLE/USER etc.,)
queries in the default configuration (cassandra.yaml) exclude list to avoid
oops for operators, since that is the only query type that log passwords in
plain text and all other places they are not.
Thanks,
Vinay
On Thu, Jun 3, 2021 at 3:58 PM benedict@apache.org <be...@apache.org>
wrote:
> I think it can be argued that this is a pretty serious bug for a newly
> introduced feature, and qualifies for inclusion in an RC, but I don’t
> personally have a strong opinion on if this should happen.
>
> I can’t imagine how this would be an _exception_ for inclusion in 4.0.1
> though.
>
> From: Mick Semb Wever <mc...@apache.org>
> Date: Thursday, 3 June 2021 at 22:45
> To: dev@cassandra.apache.org <de...@cassandra.apache.org>
> Subject: Re: Obfuscation of passwords in audit loging, in or not in 4.0?
> Thanks for raising this Stefan.
>
>
>
> > While I humbly think this is 4.0-worthy, the process we have, as far
> > as I know, is that there should be only critical fixes in 4.0 so I
> > guess this will go to 4.0.1, right? Or does this qualify to go to 4.0
> > still?
> >
>
>
> I believe the question here is whether this patch is worthy of an exception
> to go to 4.0.x. (i.e. 4.0.1)
> At this point in time all improvements would be by default slated for 4.x
> (i.e. 4.1)
>
> It does not qualify as a RC critical bug for 4.0.0.
>
> Looking at the patch it is simple, and one could almost consider it a
> security fix on a new 4.0 feature, so I'd say it's a valid exception for
> 4.0.x.
> Keen to hear what others think. And how we should go about requesting such
> exceptions for non-bugs during each annual release cycle.
>
Re: Obfuscation of passwords in audit loging, in or not in 4.0?
Posted by "benedict@apache.org" <be...@apache.org>.
I think it can be argued that this is a pretty serious bug for a newly introduced feature, and qualifies for inclusion in an RC, but I don’t personally have a strong opinion on if this should happen.
I can’t imagine how this would be an _exception_ for inclusion in 4.0.1 though.
From: Mick Semb Wever <mc...@apache.org>
Date: Thursday, 3 June 2021 at 22:45
To: dev@cassandra.apache.org <de...@cassandra.apache.org>
Subject: Re: Obfuscation of passwords in audit loging, in or not in 4.0?
Thanks for raising this Stefan.
> While I humbly think this is 4.0-worthy, the process we have, as far
> as I know, is that there should be only critical fixes in 4.0 so I
> guess this will go to 4.0.1, right? Or does this qualify to go to 4.0
> still?
>
I believe the question here is whether this patch is worthy of an exception
to go to 4.0.x. (i.e. 4.0.1)
At this point in time all improvements would be by default slated for 4.x
(i.e. 4.1)
It does not qualify as a RC critical bug for 4.0.0.
Looking at the patch it is simple, and one could almost consider it a
security fix on a new 4.0 feature, so I'd say it's a valid exception for
4.0.x.
Keen to hear what others think. And how we should go about requesting such
exceptions for non-bugs during each annual release cycle.
Re: Obfuscation of passwords in audit loging, in or not in 4.0?
Posted by Mick Semb Wever <mc...@apache.org>.
Thanks for raising this Stefan.
> While I humbly think this is 4.0-worthy, the process we have, as far
> as I know, is that there should be only critical fixes in 4.0 so I
> guess this will go to 4.0.1, right? Or does this qualify to go to 4.0
> still?
>
I believe the question here is whether this patch is worthy of an exception
to go to 4.0.x. (i.e. 4.0.1)
At this point in time all improvements would be by default slated for 4.x
(i.e. 4.1)
It does not qualify as a RC critical bug for 4.0.0.
Looking at the patch it is simple, and one could almost consider it a
security fix on a new 4.0 feature, so I'd say it's a valid exception for
4.0.x.
Keen to hear what others think. And how we should go about requesting such
exceptions for non-bugs during each annual release cycle.
Re: Obfuscation of passwords in audit loging, in or not in 4.0?
Posted by Nate McCall <zz...@gmail.com>.
On Fri, Jun 4, 2021 at 8:53 AM Ekaterina Dimitrova <e....@gmail.com>
wrote:
> One more point - if we keep the workaround, that should be documented with
> big red letters for the users.
>
>
Agree with addressing this with some docs.
Good catch, Stefan. Per your question on obsfucation - IMO, IME passwords
should never be in the clear.
Re: Obfuscation of passwords in audit loging, in or not in 4.0?
Posted by Ekaterina Dimitrova <e....@gmail.com>.
One more point - if we keep the workaround, that should be documented with
big red letters for the users.
On Thu, 3 Jun 2021 at 16:38, Ekaterina Dimitrova <e....@gmail.com>
wrote:
> Hi Stefan,
> Thank you for bringing this to the list. Truly appreciate it!
> Honestly, I have mixed feelings. While I am sure it is a great work, I
> think that anything classified as improvement and not a bug which has a
> current workaround(that is what I understood from your email without
> looking at the ticket itself) shouldn’t be merged at this point to
> cassandra-4.0.
> I am open to hear different perspective but this is my current view after
> spending big part of my day working on the Cassandra CI latest issues.
> To be clear, this is no expression of disbelief in your or anyone else
> work but rather practical opinion from seeing how unstable could be our CI
> and how close we probably are to getting the release out.
> Please let me know what you think.
> Best regards,
> Ekaterina
>
>
>
> On Thu, 3 Jun 2021 at 16:24, Stefan Miklosovic <
> stefan.miklosovic@instaclustr.com> wrote:
>
>> Hi list,
>>
>> During our evaluation of 4.0 internally, we noticed that there are
>> passwords in the plaintext in audit logging (and in fql). While I was
>> going through CASSANDRA-12151, I noticed that the password obfuscation
>> in these components was planned but it was never implemented and it
>> was merged without it, probably it was just lost in the process.
>>
>> There is ongoing effort in CASSANDRA-16669 to fix this and we are
>> almost there, it is a rather easy fix, but the question is: what is
>> this actually supposed to be merged into?
>>
>> While I humbly think this is 4.0-worthy, the process we have, as far
>> as I know, is that there should be only critical fixes in 4.0 so I
>> guess this will go to 4.0.1, right? Or does this qualify to go to 4.0
>> still? Where is that line?
>>
>> The existing workaround is to exclude DCL statements from auditing but
>> in practice I can imagine that people notice this and exclude it
>> after they have already been leaked because they do not know in
>> advance it is not obfuscated.
>>
>> Are we all on the same page this should go to 4.0.x? I made my peace
>> with it, I just want to double check that people are aware of this and
>> 4.0 will by default display passwords in audit logs in plain text
>> otherwise.
>>
>> One sub-question - do you think that FQL should _not_ obfuscate it? As
>> it is meant to replay it all, replaying obfuscated passwords does not
>> make a lot of sense but on the other hand I am not sure we want to
>> have them in the logs. What is your idea around this?
>>
>> Regards
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
>> For additional commands, e-mail: dev-help@cassandra.apache.org
>>
>>
Re: Obfuscation of passwords in audit loging, in or not in 4.0?
Posted by Ekaterina Dimitrova <e....@gmail.com>.
Hi Stefan,
Thank you for bringing this to the list. Truly appreciate it!
Honestly, I have mixed feelings. While I am sure it is a great work, I
think that anything classified as improvement and not a bug which has a
current workaround(that is what I understood from your email without
looking at the ticket itself) shouldn’t be merged at this point to
cassandra-4.0.
I am open to hear different perspective but this is my current view after
spending big part of my day working on the Cassandra CI latest issues.
To be clear, this is no expression of disbelief in your or anyone else work
but rather practical opinion from seeing how unstable could be our CI and
how close we probably are to getting the release out.
Please let me know what you think.
Best regards,
Ekaterina
On Thu, 3 Jun 2021 at 16:24, Stefan Miklosovic <
stefan.miklosovic@instaclustr.com> wrote:
> Hi list,
>
> During our evaluation of 4.0 internally, we noticed that there are
> passwords in the plaintext in audit logging (and in fql). While I was
> going through CASSANDRA-12151, I noticed that the password obfuscation
> in these components was planned but it was never implemented and it
> was merged without it, probably it was just lost in the process.
>
> There is ongoing effort in CASSANDRA-16669 to fix this and we are
> almost there, it is a rather easy fix, but the question is: what is
> this actually supposed to be merged into?
>
> While I humbly think this is 4.0-worthy, the process we have, as far
> as I know, is that there should be only critical fixes in 4.0 so I
> guess this will go to 4.0.1, right? Or does this qualify to go to 4.0
> still? Where is that line?
>
> The existing workaround is to exclude DCL statements from auditing but
> in practice I can imagine that people notice this and exclude it
> after they have already been leaked because they do not know in
> advance it is not obfuscated.
>
> Are we all on the same page this should go to 4.0.x? I made my peace
> with it, I just want to double check that people are aware of this and
> 4.0 will by default display passwords in audit logs in plain text
> otherwise.
>
> One sub-question - do you think that FQL should _not_ obfuscate it? As
> it is meant to replay it all, replaying obfuscated passwords does not
> make a lot of sense but on the other hand I am not sure we want to
> have them in the logs. What is your idea around this?
>
> Regards
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> For additional commands, e-mail: dev-help@cassandra.apache.org
>
>