Re: [VOTE] Revising release gating criteria and CI systems

[Mick Semb Wever]

+1



On Sat, 8 Oct 2022 at 14:31, Josh McKenzie  wrote:

> DISCUSS thread:
> https://lists.apache.org/thread/o166v7nr9lxnzdy5511tv40rr9t6zbrw
>
> Revise Release Lifecycle cwiki page (
> https://cwiki.apache.org/confluence/display/CASSANDRA/Release+Lifecycle):
>  - Ensure we have parity on jobs run and coverage between circle and asf-ci
>  - Allow usage of circleci as gatekeeper for releases. A release will
> require 1 green run for beta, 3 green runs consecutively for ga
>  - No new consistent regressions on CI for asf compared to prior branches
>  - Explicitly do not consider ci-cassandra asf flaky tests as release
> blockers
>
> Changes to codify into documentation (
> https://cassandra.apache.org/_/development/how_to_commit.html):
>  - On patch before commit, multiplex @500 all new tests, changed tests, or
> expected to be impacted tests ("expected to be impacted" piece pending
> multi-class multiplexing support).
>  - Add support for / documentation for multi-class specification in
> multiplexer and document
>
> Add informal project commitment during next major release lifecycle to
> continue working on bringing asf ci-cassandra up to where it can be formal
> gatekeeper for release.
>
> ---
> The vote for these revisions will run through EoD 10/12/22 to give us the
> weekend + 72 business hours.
>

Re: [VOTE] Revising release gating criteria and CI systems

[Benjamin Lerer]

+1

Le mar. 11 oct. 2022 à 09:51, Mick Semb Wever  a écrit :

>
> +1
>
>
>
> On Sat, 8 Oct 2022 at 14:31, Josh McKenzie  wrote:
>
>> DISCUSS thread:
>> https://lists.apache.org/thread/o166v7nr9lxnzdy5511tv40rr9t6zbrw
>>
>> Revise Release Lifecycle cwiki page (
>> https://cwiki.apache.org/confluence/display/CASSANDRA/Release+Lifecycle):
>>  - Ensure we have parity on jobs run and coverage between circle and
>> asf-ci
>>  - Allow usage of circleci as gatekeeper for releases. A release will
>> require 1 green run for beta, 3 green runs consecutively for ga
>>  - No new consistent regressions on CI for asf compared to prior branches
>>  - Explicitly do not consider ci-cassandra asf flaky tests as release
>> blockers
>>
>> Changes to codify into documentation (
>> https://cassandra.apache.org/_/development/how_to_commit.html):
>>  - On patch before commit, multiplex @500 all new tests, changed tests,
>> or expected to be impacted tests ("expected to be impacted" piece pending
>> multi-class multiplexing support).
>>  - Add support for / documentation for multi-class specification in
>> multiplexer and document
>>
>> Add informal project commitment during next major release lifecycle to
>> continue working on bringing asf ci-cassandra up to where it can be formal
>> gatekeeper for release.
>>
>> ---
>> The vote for these revisions will run through EoD 10/12/22 to give us the
>> weekend + 72 business hours.
>>
>

Re: [VOTE] Revising release gating criteria and CI systems

[Brandon Williams]

+1

On Sat, Oct 8, 2022 at 7:30 AM Josh McKenzie  wrote:
>
> DISCUSS thread: 
> https://lists.apache.org/thread/o166v7nr9lxnzdy5511tv40rr9t6zbrw
>
> Revise Release Lifecycle cwiki page 
> (https://cwiki.apache.org/confluence/display/CASSANDRA/Release+Lifecycle):
>  - Ensure we have parity on jobs run and coverage between circle and asf-ci
>  - Allow usage of circleci as gatekeeper for releases. A release will require 
> 1 green run for beta, 3 green runs consecutively for ga
>  - No new consistent regressions on CI for asf compared to prior branches
>  - Explicitly do not consider ci-cassandra asf flaky tests as release blockers
>
> Changes to codify into documentation 
> (https://cassandra.apache.org/_/development/how_to_commit.html):
>  - On patch before commit, multiplex @500 all new tests, changed tests, or 
> expected to be impacted tests ("expected to be impacted" piece pending 
> multi-class multiplexing support).
>  - Add support for / documentation for multi-class specification in 
> multiplexer and document
>
> Add informal project commitment during next major release lifecycle to 
> continue working on bringing asf ci-cassandra up to where it can be formal 
> gatekeeper for release.
>
> ---
> The vote for these revisions will run through EoD 10/12/22 to give us the 
> weekend + 72 business hours.

Re: [VOTE] Revising release gating criteria and CI systems

[Andrés de la Peña]

+1

On Tue, 11 Oct 2022 at 11:57, Brandon Williams  wrote:

> +1
>
> On Sat, Oct 8, 2022 at 7:30 AM Josh McKenzie  wrote:
> >
> > DISCUSS thread:
> https://lists.apache.org/thread/o166v7nr9lxnzdy5511tv40rr9t6zbrw
> >
> > Revise Release Lifecycle cwiki page (
> https://cwiki.apache.org/confluence/display/CASSANDRA/Release+Lifecycle):
> >  - Ensure we have parity on jobs run and coverage between circle and
> asf-ci
> >  - Allow usage of circleci as gatekeeper for releases. A release will
> require 1 green run for beta, 3 green runs consecutively for ga
> >  - No new consistent regressions on CI for asf compared to prior branches
> >  - Explicitly do not consider ci-cassandra asf flaky tests as release
> blockers
> >
> > Changes to codify into documentation (
> https://cassandra.apache.org/_/development/how_to_commit.html):
> >  - On patch before commit, multiplex @500 all new tests, changed tests,
> or expected to be impacted tests ("expected to be impacted" piece pending
> multi-class multiplexing support).
> >  - Add support for / documentation for multi-class specification in
> multiplexer and document
> >
> > Add informal project commitment during next major release lifecycle to
> continue working on bringing asf ci-cassandra up to where it can be formal
> gatekeeper for release.
> >
> > ---
> > The vote for these revisions will run through EoD 10/12/22 to give us
> the weekend + 72 business hours.
>

Re: [VOTE] Revising release gating criteria and CI systems

[Aleksey Yeshchenko]

Sure, +1

> On 11 Oct 2022, at 13:15, Andrés de la Peña  wrote:
> 
> +1
> 
> On Tue, 11 Oct 2022 at 11:57, Brandon Williams  > wrote:
> +1
> 
> On Sat, Oct 8, 2022 at 7:30 AM Josh McKenzie  > wrote:
> >
> > DISCUSS thread: 
> > https://lists.apache.org/thread/o166v7nr9lxnzdy5511tv40rr9t6zbrw 
> > 
> >
> > Revise Release Lifecycle cwiki page 
> > (https://cwiki.apache.org/confluence/display/CASSANDRA/Release+Lifecycle 
> > ):
> >  - Ensure we have parity on jobs run and coverage between circle and asf-ci
> >  - Allow usage of circleci as gatekeeper for releases. A release will 
> > require 1 green run for beta, 3 green runs consecutively for ga
> >  - No new consistent regressions on CI for asf compared to prior branches
> >  - Explicitly do not consider ci-cassandra asf flaky tests as release 
> > blockers
> >
> > Changes to codify into documentation 
> > (https://cassandra.apache.org/_/development/how_to_commit.html 
> > ):
> >  - On patch before commit, multiplex @500 all new tests, changed tests, or 
> > expected to be impacted tests ("expected to be impacted" piece pending 
> > multi-class multiplexing support).
> >  - Add support for / documentation for multi-class specification in 
> > multiplexer and document
> >
> > Add informal project commitment during next major release lifecycle to 
> > continue working on bringing asf ci-cassandra up to where it can be formal 
> > gatekeeper for release.
> >
> > ---
> > The vote for these revisions will run through EoD 10/12/22 to give us the 
> > weekend + 72 business hours.

Re: [Discuss] CEP-24 Password validation and generation

[Josh McKenzie]

> if we do that, we should also restrict the frequency how often a user can 
> change the password. Lets think this through. If the depth of historical 
> verification is 5 passwords, a user just has to regenerate a password 5 times 
> in a row an he can use the same one
I may be misunderstanding, but this strikes me as in the "we can only do so 
much to prevent people from doing stupid things" category. If someone's so 
hell-bent on circumventing their company's attempts at security they're 
probably much more at risk of running unidentified attachments or giving out 
credentials over the phone rather than finding clever ways to work around 
annoying password rotation rules on their db accounts right?

On Mon, Oct 10, 2022, at 4:08 PM, Miklosovic, Stefan wrote:
> Hi Brad,
> 
> your link about not enforcing regular password expiration for users is spot 
> on. For these reasons I decided to not expand that CEP in that direction. 
> Sure, technically possible, but practically questionable. I think that all 
> these guides and recommendations should be looked at from the perspective of 
> the system they are meant to be implemented in. Enforcing password to be 
> changed in a database system is rather interesting take. After I briefly took 
> a look, I do not think there is a database on the market which is enforcing 
> this. On the other hand, for example, Neo4j forces you to change the password 
> on the first login as the default one is "neo4j" for user "neo4j". This does 
> make sense to implement for Cassandra as well. I do consider password 
> "cassandra" for role "cassandra" very insecure and it is not forced by 
> anybody to change it. However, it is quite interesting problem how to achieve 
> that.
> 
> Also, the reason I want to leave out historical verification of passwords in 
> (at least the initial) implementation is that if we do that, we should also 
> restrict the frequency how often a user can change the password. Lets think 
> this through. If the depth of historical verification is 5 passwords, a user 
> just has to regenerate a password 5 times in a row an he can use the same 
> one. So implmenting this without restricting how often he can change his 
> password does not make sense. We can indeed explore this further but I feel 
> like the initial implementation should not deal with this for now.
> 
> When it comes to section 5.1.1.2 of NIST document, as already mention at the 
> bottom of the CEP, we used Appendix A of this (1) to model what the good 
> password should be. Your link is way more descriptive though. Particularly 
> interesting points are these:
> 
> - Passwords obtained from previous breach corpuses.
> - Dictionary words.
> - Repetitive or sequential characters (e.g. ‘aa’, ‘1234abcd’).
> - Context-specific words, such as the name of the service, the username, and 
> derivatives thereof.
> 
> I believe that points 1), 2) and 4) can be implemented easily as checking the 
> password against a dictionary. The library we want to use is able to check 
> the password against a dictionary. Dictionary check can be also implemented 
> as a separate ticket which would just expand the functionality of 
> DefaultPasswordValidator. I do not have a problem to include dictionary check 
> into the first iteration as well.
> 
> Repetitive or sequential characters are already covered in the POC 
> implementation.
> 
> The document you linked also contains this:
> 
> Verifiers SHOULD offer guidance to the subscriber, such as a 
> password-strength meter [Meters], to assist the user in choosing a strong 
> memorized secret. This is particularly important following the rejection of a 
> memorized secret on the above list as it discourages trivial modification of 
> listed (and likely very weak) memorized secrets
> 
> We are already doing this, quite intelligently, by telling a user what is 
> wrong with his password that it can not be used (e.g. that it does not 
> contain so and so number of specific characters). The "meter" is also there - 
> we have three levels - OK password, password with a warning and failed 
> password. We inform a user about the strength of his password retroactively - 
> we do not tell him what the password should be before he tries to set one 
> however I think that is acceptable when using Cassandra and cqlsh in console 
> environment.
> 
> (1) https://pages.nist.gov/800-63-3/sp800-63b.html#appA
> 
> From: Brad 
> Sent: Monday, October 10, 2022 17:43
> To: dev@cassandra.apache.org
> Subject: Re: [Discuss] CEP-24 Password validation and generation
> 
> NetApp Security WARNING: This is an external email. Do not click links or 
> open attachments unless you recognize the sender and know the content is safe.
> 
> 
> 
> I would suggest reviewing the guidelines in sec in 5.1.1.2 of NIST Special 
> Publication 
> 800-63B and the 
> NCSC Password policy: updating your app

Re: [Discuss] CEP-24 Password validation and generation

[Derek Chen-Becker]

On top of what Josh said, a corresponding requirement here would be
auditing. A password complexity and/or history policy is one piece of
security posture, but is itself insufficient to be considered "secure".
What kind of logs will this new policy checker emit that the folks
responsible for security for a given cluster can parse, process, and report
on?

Cheers,

Derek

On Tue, Oct 11, 2022 at 9:07 AM Josh McKenzie  wrote:

> if we do that, we should also restrict the frequency how often a user can
> change the password. Lets think this through. If the depth of historical
> verification is 5 passwords, a user just has to regenerate a password 5
> times in a row an he can use the same one
>
> I may be misunderstanding, but this strikes me as in the "we can only do
> so much to prevent people from doing stupid things" category. If someone's
> so hell-bent on circumventing their company's attempts at security they're
> probably much more at risk of running unidentified attachments or giving
> out credentials over the phone rather than finding clever ways to work
> around annoying password rotation rules on their db accounts right?
>
> On Mon, Oct 10, 2022, at 4:08 PM, Miklosovic, Stefan wrote:
>
> Hi Brad,
>
> your link about not enforcing regular password expiration for users is
> spot on. For these reasons I decided to not expand that CEP in that
> direction. Sure, technically possible, but practically questionable. I
> think that all these guides and recommendations should be looked at from
> the perspective of the system they are meant to be implemented in.
> Enforcing password to be changed in a database system is rather interesting
> take. After I briefly took a look, I do not think there is a database on
> the market which is enforcing this. On the other hand, for example, Neo4j
> forces you to change the password on the first login as the default one is
> "neo4j" for user "neo4j". This does make sense to implement for Cassandra
> as well. I do consider password "cassandra" for role "cassandra" very
> insecure and it is not forced by anybody to change it. However, it is quite
> interesting problem how to achieve that.
>
> Also, the reason I want to leave out historical verification of passwords
> in (at least the initial) implementation is that if we do that, we should
> also restrict the frequency how often a user can change the password. Lets
> think this through. If the depth of historical verification is 5 passwords,
> a user just has to regenerate a password 5 times in a row an he can use the
> same one. So implmenting this without restricting how often he can change
> his password does not make sense. We can indeed explore this further but I
> feel like the initial implementation should not deal with this for now.
>
> When it comes to section 5.1.1.2 of NIST document, as already mention at
> the bottom of the CEP, we used Appendix A of this (1) to model what the
> good password should be. Your link is way more descriptive though.
> Particularly interesting points are these:
>
> - Passwords obtained from previous breach corpuses.
> - Dictionary words.
> - Repetitive or sequential characters (e.g. ‘aa’, ‘1234abcd’).
> - Context-specific words, such as the name of the service, the username,
> and derivatives thereof.
>
> I believe that points 1), 2) and 4) can be implemented easily as checking
> the password against a dictionary. The library we want to use is able to
> check the password against a dictionary. Dictionary check can be also
> implemented as a separate ticket which would just expand the functionality
> of DefaultPasswordValidator. I do not have a problem to include dictionary
> check into the first iteration as well.
>
> Repetitive or sequential characters are already covered in the POC
> implementation.
>
> The document you linked also contains this:
>
> Verifiers SHOULD offer guidance to the subscriber, such as a
> password-strength meter [Meters], to assist the user in choosing a strong
> memorized secret. This is particularly important following the rejection of
> a memorized secret on the above list as it discourages trivial modification
> of listed (and likely very weak) memorized secrets
>
> We are already doing this, quite intelligently, by telling a user what is
> wrong with his password that it can not be used (e.g. that it does not
> contain so and so number of specific characters). The "meter" is also there
> - we have three levels - OK password, password with a warning and failed
> password. We inform a user about the strength of his password retroactively
> - we do not tell him what the password should be before he tries to set one
> however I think that is acceptable when using Cassandra and cqlsh in
> console environment.
>
> (1) https://pages.nist.gov/800-63-3/sp800-63b.html#appA
> 
> From: Brad 
> Sent: Monday, October 10, 2022 17:43
> To: dev@cassandra.apache.org
> Subject: Re: [Discuss] CEP-24 Password validation and gener

Re: [Discuss] CEP-24 Password validation and generation

[Miklosovic, Stefan]

I dont follow, sorry. What logs do you mean? What would you like to see?

The auditing framework we already do have in place will log that somebody tried 
to create (or alter) a role with this and that password and it failed (password 
would be redacted). If you use "with generated password", that password will 
not be even shown in audit log. I am not completely sure if the warning is 
logged too if password is not valid (I do think that only CQL command itself is 
audit-logged).

The configuration of validator is in cassandra.yaml. Folks can review that?

I am sorry if I am missing something here, could you expand what you mean?

To Josh:

You are probably right but it is so easy to bypass that it is questionable why 
it is actually there. All it takes is to do "alter role myself with generated 
password" (literally), 5 times in a row and you can set the original one back. 
One positive fact is that such password, even same as the original one, would 
still have to be valid, but it just might be same as it was.


From: Derek Chen-Becker 
Sent: Tuesday, October 11, 2022 17:14
To: dev@cassandra.apache.org
Subject: Re: [Discuss] CEP-24 Password validation and generation

NetApp Security WARNING: This is an external email. Do not click links or open 
attachments unless you recognize the sender and know the content is safe.



On top of what Josh said, a corresponding requirement here would be auditing. A 
password complexity and/or history policy is one piece of security posture, but 
is itself insufficient to be considered "secure". What kind of logs will this 
new policy checker emit that the folks responsible for security for a given 
cluster can parse, process, and report on?

Cheers,

Derek

On Tue, Oct 11, 2022 at 9:07 AM Josh McKenzie 
mailto:jmcken...@apache.org>> wrote:
if we do that, we should also restrict the frequency how often a user can 
change the password. Lets think this through. If the depth of historical 
verification is 5 passwords, a user just has to regenerate a password 5 times 
in a row an he can use the same one
I may be misunderstanding, but this strikes me as in the "we can only do so 
much to prevent people from doing stupid things" category. If someone's so 
hell-bent on circumventing their company's attempts at security they're 
probably much more at risk of running unidentified attachments or giving out 
credentials over the phone rather than finding clever ways to work around 
annoying password rotation rules on their db accounts right?

On Mon, Oct 10, 2022, at 4:08 PM, Miklosovic, Stefan wrote:
Hi Brad,

your link about not enforcing regular password expiration for users is spot on. 
For these reasons I decided to not expand that CEP in that direction. Sure, 
technically possible, but practically questionable. I think that all these 
guides and recommendations should be looked at from the perspective of the 
system they are meant to be implemented in. Enforcing password to be changed in 
a database system is rather interesting take. After I briefly took a look, I do 
not think there is a database on the market which is enforcing this. On the 
other hand, for example, Neo4j forces you to change the password on the first 
login as the default one is "neo4j" for user "neo4j". This does make sense to 
implement for Cassandra as well. I do consider password "cassandra" for role 
"cassandra" very insecure and it is not forced by anybody to change it. 
However, it is quite interesting problem how to achieve that.

Also, the reason I want to leave out historical verification of passwords in 
(at least the initial) implementation is that if we do that, we should also 
restrict the frequency how often a user can change the password. Lets think 
this through. If the depth of historical verification is 5 passwords, a user 
just has to regenerate a password 5 times in a row an he can use the same one. 
So implmenting this without restricting how often he can change his password 
does not make sense. We can indeed explore this further but I feel like the 
initial implementation should not deal with this for now.

When it comes to section 5.1.1.2 of NIST document, as already mention at the 
bottom of the CEP, we used Appendix A of this (1) to model what the good 
password should be. Your link is way more descriptive though. Particularly 
interesting points are these:

- Passwords obtained from previous breach corpuses.
- Dictionary words.
- Repetitive or sequential characters (e.g. ‘aa’, ‘1234abcd’).
- Context-specific words, such as the name of the service, the username, and 
derivatives thereof.

I believe that points 1), 2) and 4) can be implemented easily as checking the 
password against a dictionary. The library we want to use is able to check the 
password against a dictionary. Dictionary check can be also implemented as a 
separate ticket which would just expand the functionality of 
DefaultPasswordValidator. I do not have a problem to i

Re: [Discuss] CEP-24 Password validation and generation

[Brad]

I'd agree that password expiry should be avoided. Regarding password
complexity, could we offer a meter instead of specific rules?  The NIST
guideline states:

Verifiers SHOULD NOT impose other composition rules (e.g., requiring
mixtures of different character types or prohibiting consecutively repeated
characters) for memorized secrets.


The CEP-24 draft has a different perspective and states:

   - it has to fulfil n out of these 4 characteristics, number of
   characters per characteristic is again configurable both for warning and
   failure thresholds
  - contains upper case characters
  - contains lower case characters
  - contains digits
  - contains special characters (only ascii chars)


One thing to bear in mind is that the majority of enterprises with
Cassandra will use a SSO solution for authentication.  But test and dev
installations will more frequently use passwords.

Regards,

Brad
On Mon, Oct 10, 2022 at 4:09 PM Miklosovic, Stefan <
stefan.mikloso...@netapp.com> wrote:

> Hi Brad,
>
> your link about not enforcing regular password expiration for users is
> spot on. For these reasons I decided to not expand that CEP in that
> direction. Sure, technically possible, but practically questionable. I
> think that all these guides and recommendations should be looked at from
> the perspective of the system they are meant to be implemented in.
> Enforcing password to be changed in a database system is rather interesting
> take. After I briefly took a look, I do not think there is a database on
> the market which is enforcing this. On the other hand, for example, Neo4j
> forces you to change the password on the first login as the default one is
> "neo4j" for user "neo4j". This does make sense to implement for Cassandra
> as well. I do consider password "cassandra" for role "cassandra" very
> insecure and it is not forced by anybody to change it. However, it is quite
> interesting problem how to achieve that.
>
> Also, the reason I want to leave out historical verification of passwords
> in (at least the initial) implementation is that if we do that, we should
> also restrict the frequency how often a user can change the password. Lets
> think this through. If the depth of historical verification is 5 passwords,
> a user just has to regenerate a password 5 times in a row an he can use the
> same one. So implmenting this without restricting how often he can change
> his password does not make sense. We can indeed explore this further but I
> feel like the initial implementation should not deal with this for now.
>
> When it comes to section 5.1.1.2 of NIST document, as already mention at
> the bottom of the CEP, we used Appendix A of this (1) to model what the
> good password should be. Your link is way more descriptive though.
> Particularly interesting points are these:
>
> - Passwords obtained from previous breach corpuses.
> - Dictionary words.
> - Repetitive or sequential characters (e.g. ‘aa’, ‘1234abcd’).
> - Context-specific words, such as the name of the service, the username,
> and derivatives thereof.
>
> I believe that points 1), 2) and 4) can be implemented easily as checking
> the password against a dictionary. The library we want to use is able to
> check the password against a dictionary. Dictionary check can be also
> implemented as a separate ticket which would just expand the functionality
> of DefaultPasswordValidator. I do not have a problem to include dictionary
> check into the first iteration as well.
>
> Repetitive or sequential characters are already covered in the POC
> implementation.
>
> The document you linked also contains this:
>
> Verifiers SHOULD offer guidance to the subscriber, such as a
> password-strength meter [Meters], to assist the user in choosing a strong
> memorized secret. This is particularly important following the rejection of
> a memorized secret on the above list as it discourages trivial modification
> of listed (and likely very weak) memorized secrets
>
> We are already doing this, quite intelligently, by telling a user what is
> wrong with his password that it can not be used (e.g. that it does not
> contain so and so number of specific characters). The "meter" is also there
> - we have three levels - OK password, password with a warning and failed
> password. We inform a user about the strength of his password retroactively
> - we do not tell him what the password should be before he tries to set one
> however I think that is acceptable when using Cassandra and cqlsh in
> console environment.
>
> (1) https://pages.nist.gov/800-63-3/sp800-63b.html#appA
> 
> From: Brad 
> Sent: Monday, October 10, 2022 17:43
> To: dev@cassandra.apache.org
> Subject: Re: [Discuss] CEP-24 Password validation and generation
>
> NetApp Security WARNING: This is an external email. Do not click links or
> open attachments unless you recognize the sender and know the content is
> safe.
>
>
>
> I would suggest rev

Re: [Discuss] CEP-24 Password validation and generation

[Derek Chen-Becker]

I know we log that the password change attempt was made, but we should
consider logging why it was rejected. As part of that, we may want to
consider how we format that message to make it easy for an auditing system
to parse. We should never log the actual password, or even a redacted
version; apologies if it sounded like I was suggesting that.

Cheers,

Derek

On Tue, Oct 11, 2022 at 9:36 AM Miklosovic, Stefan <
stefan.mikloso...@netapp.com> wrote:

> I dont follow, sorry. What logs do you mean? What would you like to see?
>
> The auditing framework we already do have in place will log that somebody
> tried to create (or alter) a role with this and that password and it failed
> (password would be redacted). If you use "with generated password", that
> password will not be even shown in audit log. I am not completely sure if
> the warning is logged too if password is not valid (I do think that only
> CQL command itself is audit-logged).
>
> The configuration of validator is in cassandra.yaml. Folks can review that?
>
> I am sorry if I am missing something here, could you expand what you mean?
>
> To Josh:
>
> You are probably right but it is so easy to bypass that it is questionable
> why it is actually there. All it takes is to do "alter role myself with
> generated password" (literally), 5 times in a row and you can set the
> original one back. One positive fact is that such password, even same as
> the original one, would still have to be valid, but it just might be same
> as it was.
>
> 
> From: Derek Chen-Becker 
> Sent: Tuesday, October 11, 2022 17:14
> To: dev@cassandra.apache.org
> Subject: Re: [Discuss] CEP-24 Password validation and generation
>
> NetApp Security WARNING: This is an external email. Do not click links or
> open attachments unless you recognize the sender and know the content is
> safe.
>
>
>
> On top of what Josh said, a corresponding requirement here would be
> auditing. A password complexity and/or history policy is one piece of
> security posture, but is itself insufficient to be considered "secure".
> What kind of logs will this new policy checker emit that the folks
> responsible for security for a given cluster can parse, process, and report
> on?
>
> Cheers,
>
> Derek
>
> On Tue, Oct 11, 2022 at 9:07 AM Josh McKenzie  > wrote:
> if we do that, we should also restrict the frequency how often a user can
> change the password. Lets think this through. If the depth of historical
> verification is 5 passwords, a user just has to regenerate a password 5
> times in a row an he can use the same one
> I may be misunderstanding, but this strikes me as in the "we can only do
> so much to prevent people from doing stupid things" category. If someone's
> so hell-bent on circumventing their company's attempts at security they're
> probably much more at risk of running unidentified attachments or giving
> out credentials over the phone rather than finding clever ways to work
> around annoying password rotation rules on their db accounts right?
>
> On Mon, Oct 10, 2022, at 4:08 PM, Miklosovic, Stefan wrote:
> Hi Brad,
>
> your link about not enforcing regular password expiration for users is
> spot on. For these reasons I decided to not expand that CEP in that
> direction. Sure, technically possible, but practically questionable. I
> think that all these guides and recommendations should be looked at from
> the perspective of the system they are meant to be implemented in.
> Enforcing password to be changed in a database system is rather interesting
> take. After I briefly took a look, I do not think there is a database on
> the market which is enforcing this. On the other hand, for example, Neo4j
> forces you to change the password on the first login as the default one is
> "neo4j" for user "neo4j". This does make sense to implement for Cassandra
> as well. I do consider password "cassandra" for role "cassandra" very
> insecure and it is not forced by anybody to change it. However, it is quite
> interesting problem how to achieve that.
>
> Also, the reason I want to leave out historical verification of passwords
> in (at least the initial) implementation is that if we do that, we should
> also restrict the frequency how often a user can change the password. Lets
> think this through. If the depth of historical verification is 5 passwords,
> a user just has to regenerate a password 5 times in a row an he can use the
> same one. So implmenting this without restricting how often he can change
> his password does not make sense. We can indeed explore this further but I
> feel like the initial implementation should not deal with this for now.
>
> When it comes to section 5.1.1.2 of NIST document, as already mention at
> the bottom of the CEP, we used Appendix A of this (1) to model what the
> good password should be. Your link is way more descriptive though.
> Particularly interesting points are these:
>
> - Passwords obtaine

Re: [Discuss] CEP-24 Password validation and generation

[Miklosovic, Stefan]

Honestly, it seems to me that the link you sent from NIST is not congruent with 
itself as a whole, they mention this:

For example, the list MAY include, but is not limited to:

Passwords obtained from previous breach corpuses.
Dictionary words.
Repetitive or sequential characters (e.g. ‘aa’, ‘1234abcd’).

but on the other hand they mention that we should not prohibit consecutively 
repeated characters?

This does not clash with SSO, whatever that might be. I do not think that is a 
problem. If you have, for example, Kerberos authenticator, that completely 
bypasses passwords in Cassandra. I would say that the validator might be tied 
to PasswordAuthenticator only.

It is important to realize that we are providing a way how to make custom 
password validator if operators are using something "password based" but they 
are not using PasswordAuthenticator and they are implementing something 
special. DefaultPasswordValidator is meant to play together with out-of-the-box 
stuff Cassandra offers and if one finds it necessary to tweak it he might 
implement it as he wishes.


From: Brad 
Sent: Tuesday, October 11, 2022 17:41
To: dev@cassandra.apache.org
Subject: Re: [Discuss] CEP-24 Password validation and generation

NetApp Security WARNING: This is an external email. Do not click links or open 
attachments unless you recognize the sender and know the content is safe.



I'd agree that password expiry should be avoided. Regarding password 
complexity, could we offer a meter instead of specific rules?  The NIST 
guideline states:

Verifiers SHOULD NOT impose other composition rules (e.g., requiring mixtures 
of different character types or prohibiting consecutively repeated characters) 
for memorized secrets.

The CEP-24 draft has a different perspective and states:

  *   it has to fulfil n out of these 4 characteristics, number of characters 
per characteristic is again configurable both for warning and failure thresholds
 *   contains upper case characters
 *   contains lower case characters
 *   contains digits
 *   contains special characters (only ascii chars)

One thing to bear in mind is that the majority of enterprises with Cassandra 
will use a SSO solution for authentication.  But test and dev installations 
will more frequently use passwords.

Regards,

Brad
On Mon, Oct 10, 2022 at 4:09 PM Miklosovic, Stefan 
mailto:stefan.mikloso...@netapp.com>> wrote:
Hi Brad,

your link about not enforcing regular password expiration for users is spot on. 
For these reasons I decided to not expand that CEP in that direction. Sure, 
technically possible, but practically questionable. I think that all these 
guides and recommendations should be looked at from the perspective of the 
system they are meant to be implemented in. Enforcing password to be changed in 
a database system is rather interesting take. After I briefly took a look, I do 
not think there is a database on the market which is enforcing this. On the 
other hand, for example, Neo4j forces you to change the password on the first 
login as the default one is "neo4j" for user "neo4j". This does make sense to 
implement for Cassandra as well. I do consider password "cassandra" for role 
"cassandra" very insecure and it is not forced by anybody to change it. 
However, it is quite interesting problem how to achieve that.

Also, the reason I want to leave out historical verification of passwords in 
(at least the initial) implementation is that if we do that, we should also 
restrict the frequency how often a user can change the password. Lets think 
this through. If the depth of historical verification is 5 passwords, a user 
just has to regenerate a password 5 times in a row an he can use the same one. 
So implmenting this without restricting how often he can change his password 
does not make sense. We can indeed explore this further but I feel like the 
initial implementation should not deal with this for now.

When it comes to section 5.1.1.2 of NIST document, as already mention at the 
bottom of the CEP, we used Appendix A of this (1) to model what the good 
password should be. Your link is way more descriptive though. Particularly 
interesting points are these:

- Passwords obtained from previous breach corpuses.
- Dictionary words.
- Repetitive or sequential characters (e.g. ‘aa’, ‘1234abcd’).
- Context-specific words, such as the name of the service, the username, and 
derivatives thereof.

I believe that points 1), 2) and 4) can be implemented easily as checking the 
password against a dictionary. The library we want to use is able to check the 
password against a dictionary. Dictionary check can be also implemented as a 
separate ticket which would just expand the functionality of 
DefaultPasswordValidator. I do not have a problem to include dictionary check 
into the first iteration as well.

Repetitive or sequential characters are already covered in the POC 
implementation.

The d

Re: [Discuss] CEP-24 Password validation and generation

[Miklosovic, Stefan]

"but we should consider logging why it was rejected."

Why? What is the use case? Why is it important for you to know what somebody 
tried to create a role with password "aa" (it will not be shown), just 
mentioning that they tried to create a password with a lot of repeating 
characters? What is the added value here?

I need to double check if warnings are logged as well. I'll get back to you.



From: Derek Chen-Becker 
Sent: Tuesday, October 11, 2022 17:47
To: dev@cassandra.apache.org
Subject: Re: [Discuss] CEP-24 Password validation and generation

NetApp Security WARNING: This is an external email. Do not click links or open 
attachments unless you recognize the sender and know the content is safe.



I know we log that the password change attempt was made, but we should consider 
logging why it was rejected. As part of that, we may want to consider how we 
format that message to make it easy for an auditing system to parse. We should 
never log the actual password, or even a redacted version; apologies if it 
sounded like I was suggesting that.

Cheers,

Derek

On Tue, Oct 11, 2022 at 9:36 AM Miklosovic, Stefan 
mailto:stefan.mikloso...@netapp.com>> wrote:
I dont follow, sorry. What logs do you mean? What would you like to see?

The auditing framework we already do have in place will log that somebody tried 
to create (or alter) a role with this and that password and it failed (password 
would be redacted). If you use "with generated password", that password will 
not be even shown in audit log. I am not completely sure if the warning is 
logged too if password is not valid (I do think that only CQL command itself is 
audit-logged).

The configuration of validator is in cassandra.yaml. Folks can review that?

I am sorry if I am missing something here, could you expand what you mean?

To Josh:

You are probably right but it is so easy to bypass that it is questionable why 
it is actually there. All it takes is to do "alter role myself with generated 
password" (literally), 5 times in a row and you can set the original one back. 
One positive fact is that such password, even same as the original one, would 
still have to be valid, but it just might be same as it was.


From: Derek Chen-Becker mailto:de...@chen-becker.org>>
Sent: Tuesday, October 11, 2022 17:14
To: dev@cassandra.apache.org
Subject: Re: [Discuss] CEP-24 Password validation and generation

NetApp Security WARNING: This is an external email. Do not click links or open 
attachments unless you recognize the sender and know the content is safe.



On top of what Josh said, a corresponding requirement here would be auditing. A 
password complexity and/or history policy is one piece of security posture, but 
is itself insufficient to be considered "secure". What kind of logs will this 
new policy checker emit that the folks responsible for security for a given 
cluster can parse, process, and report on?

Cheers,

Derek

On Tue, Oct 11, 2022 at 9:07 AM Josh McKenzie 
mailto:jmcken...@apache.org>>>
 wrote:
if we do that, we should also restrict the frequency how often a user can 
change the password. Lets think this through. If the depth of historical 
verification is 5 passwords, a user just has to regenerate a password 5 times 
in a row an he can use the same one
I may be misunderstanding, but this strikes me as in the "we can only do so 
much to prevent people from doing stupid things" category. If someone's so 
hell-bent on circumventing their company's attempts at security they're 
probably much more at risk of running unidentified attachments or giving out 
credentials over the phone rather than finding clever ways to work around 
annoying password rotation rules on their db accounts right?

On Mon, Oct 10, 2022, at 4:08 PM, Miklosovic, Stefan wrote:
Hi Brad,

your link about not enforcing regular password expiration for users is spot on. 
For these reasons I decided to not expand that CEP in that direction. Sure, 
technically possible, but practically questionable. I think that all these 
guides and recommendations should be looked at from the perspective of the 
system they are meant to be implemented in. Enforcing password to be changed in 
a database system is rather interesting take. After I briefly took a look, I do 
not think there is a database on the market which is enforcing this. On the 
other hand, for example, Neo4j forces you to change the password on the first 
login as the default one is "neo4j" for user "neo4j". This does make sense to 
implement for Cassandra as well. I do consider password "cassandra" for role 
"cassandra" very insecure and it is not forced by anybody to change it. 
However, it is quite interesting problem how to achieve that.

Also, the reason I want to leave out historical verification of passwords in 
(at least the initial) imp

Re: [Discuss] CEP-24 Password validation and generation

[Derek Chen-Becker]

Speaking with my operator hat on, I would want to know if there's a common
pattern that my end users hit so that I can better educate them or provide
tools (e.g. vaults) to help them manage the required complexity.

Cheers,

Derek

On Tue, Oct 11, 2022 at 10:06 AM Miklosovic, Stefan <
stefan.mikloso...@netapp.com> wrote:

> "but we should consider logging why it was rejected."
>
> Why? What is the use case? Why is it important for you to know what
> somebody tried to create a role with password "aa" (it will not be
> shown), just mentioning that they tried to create a password with a lot of
> repeating characters? What is the added value here?
>
> I need to double check if warnings are logged as well. I'll get back to
> you.
>
>
> 
> From: Derek Chen-Becker 
> Sent: Tuesday, October 11, 2022 17:47
> To: dev@cassandra.apache.org
> Subject: Re: [Discuss] CEP-24 Password validation and generation
>
> NetApp Security WARNING: This is an external email. Do not click links or
> open attachments unless you recognize the sender and know the content is
> safe.
>
>
>
> I know we log that the password change attempt was made, but we should
> consider logging why it was rejected. As part of that, we may want to
> consider how we format that message to make it easy for an auditing system
> to parse. We should never log the actual password, or even a redacted
> version; apologies if it sounded like I was suggesting that.
>
> Cheers,
>
> Derek
>
> On Tue, Oct 11, 2022 at 9:36 AM Miklosovic, Stefan <
> stefan.mikloso...@netapp.com> wrote:
> I dont follow, sorry. What logs do you mean? What would you like to see?
>
> The auditing framework we already do have in place will log that somebody
> tried to create (or alter) a role with this and that password and it failed
> (password would be redacted). If you use "with generated password", that
> password will not be even shown in audit log. I am not completely sure if
> the warning is logged too if password is not valid (I do think that only
> CQL command itself is audit-logged).
>
> The configuration of validator is in cassandra.yaml. Folks can review that?
>
> I am sorry if I am missing something here, could you expand what you mean?
>
> To Josh:
>
> You are probably right but it is so easy to bypass that it is questionable
> why it is actually there. All it takes is to do "alter role myself with
> generated password" (literally), 5 times in a row and you can set the
> original one back. One positive fact is that such password, even same as
> the original one, would still have to be valid, but it just might be same
> as it was.
>
> 
> From: Derek Chen-Becker  de...@chen-becker.org>>
> Sent: Tuesday, October 11, 2022 17:14
> To: dev@cassandra.apache.org
> Subject: Re: [Discuss] CEP-24 Password validation and generation
>
> NetApp Security WARNING: This is an external email. Do not click links or
> open attachments unless you recognize the sender and know the content is
> safe.
>
>
>
> On top of what Josh said, a corresponding requirement here would be
> auditing. A password complexity and/or history policy is one piece of
> security posture, but is itself insufficient to be considered "secure".
> What kind of logs will this new policy checker emit that the folks
> responsible for security for a given cluster can parse, process, and report
> on?
>
> Cheers,
>
> Derek
>
> On Tue, Oct 11, 2022 at 9:07 AM Josh McKenzie  >> wrote:
> if we do that, we should also restrict the frequency how often a user can
> change the password. Lets think this through. If the depth of historical
> verification is 5 passwords, a user just has to regenerate a password 5
> times in a row an he can use the same one
> I may be misunderstanding, but this strikes me as in the "we can only do
> so much to prevent people from doing stupid things" category. If someone's
> so hell-bent on circumventing their company's attempts at security they're
> probably much more at risk of running unidentified attachments or giving
> out credentials over the phone rather than finding clever ways to work
> around annoying password rotation rules on their db accounts right?
>
> On Mon, Oct 10, 2022, at 4:08 PM, Miklosovic, Stefan wrote:
> Hi Brad,
>
> your link about not enforcing regular password expiration for users is
> spot on. For these reasons I decided to not expand that CEP in that
> direction. Sure, technically possible, but practically questionable. I
> think that all these guides and recommendations should be looked at from
> the perspective of the system they are meant to be implemented in.
> Enforcing password to be changed in a database system is rather interesting
> take. After I briefly took a look, I do not think there is a database on
> the market which is enforcing this.

Re: [VOTE] Revising release gating criteria and CI systems

[Jeremiah D Jordan]

+1 nb

> On Oct 8, 2022, at 7:30 AM, Josh McKenzie  wrote:
> 
> DISCUSS thread: 
> https://lists.apache.org/thread/o166v7nr9lxnzdy5511tv40rr9t6zbrw 
> 
> 
> Revise Release Lifecycle cwiki page 
> (https://cwiki.apache.org/confluence/display/CASSANDRA/Release+Lifecycle 
> ):
>  - Ensure we have parity on jobs run and coverage between circle and asf-ci
>  - Allow usage of circleci as gatekeeper for releases. A release will require 
> 1 green run for beta, 3 green runs consecutively for ga
>  - No new consistent regressions on CI for asf compared to prior branches
>  - Explicitly do not consider ci-cassandra asf flaky tests as release blockers
> 
> Changes to codify into documentation 
> (https://cassandra.apache.org/_/development/how_to_commit.html 
> ):
>  - On patch before commit, multiplex @500 all new tests, changed tests, or 
> expected to be impacted tests ("expected to be impacted" piece pending 
> multi-class multiplexing support).
>  - Add support for / documentation for multi-class specification in 
> multiplexer and document
> 
> Add informal project commitment during next major release lifecycle to 
> continue working on bringing asf ci-cassandra up to where it can be formal 
> gatekeeper for release.
> 
> ---
> The vote for these revisions will run through EoD 10/12/22 to give us the 
> weekend + 72 business hours.

Re: [Discuss] CEP-24 Password validation and generation

[Miklosovic, Stefan]

I am afraid this is way out of scope of this CEP. I think we would be the very 
first on the database scene to offer such low-level and fine-grained 
information. I am not persuaded that this is something we should be giving a 
lot of attention right now. We have "cassandra / cassandra" credentials combo 
as default, I would say that is more important to deal with right now than 
providing very detailed information about what kind of passwords people are 
using.

Thank you very much for (not only your) insights. This is very important 
feedback and I am glad you participate in this thread. I will try to summarize 
where we are as it is easy to get lost in these emails.


From: Derek Chen-Becker 
Sent: Tuesday, October 11, 2022 18:59
To: dev@cassandra.apache.org
Subject: Re: [Discuss] CEP-24 Password validation and generation

NetApp Security WARNING: This is an external email. Do not click links or open 
attachments unless you recognize the sender and know the content is safe.



Speaking with my operator hat on, I would want to know if there's a common 
pattern that my end users hit so that I can better educate them or provide 
tools (e.g. vaults) to help them manage the required complexity.

Cheers,

Derek

On Tue, Oct 11, 2022 at 10:06 AM Miklosovic, Stefan 
mailto:stefan.mikloso...@netapp.com>> wrote:
"but we should consider logging why it was rejected."

Why? What is the use case? Why is it important for you to know what somebody 
tried to create a role with password "aa" (it will not be shown), just 
mentioning that they tried to create a password with a lot of repeating 
characters? What is the added value here?

I need to double check if warnings are logged as well. I'll get back to you.



From: Derek Chen-Becker mailto:de...@chen-becker.org>>
Sent: Tuesday, October 11, 2022 17:47
To: dev@cassandra.apache.org
Subject: Re: [Discuss] CEP-24 Password validation and generation

NetApp Security WARNING: This is an external email. Do not click links or open 
attachments unless you recognize the sender and know the content is safe.



I know we log that the password change attempt was made, but we should consider 
logging why it was rejected. As part of that, we may want to consider how we 
format that message to make it easy for an auditing system to parse. We should 
never log the actual password, or even a redacted version; apologies if it 
sounded like I was suggesting that.

Cheers,

Derek

On Tue, Oct 11, 2022 at 9:36 AM Miklosovic, Stefan 
mailto:stefan.mikloso...@netapp.com>>>
 wrote:
I dont follow, sorry. What logs do you mean? What would you like to see?

The auditing framework we already do have in place will log that somebody tried 
to create (or alter) a role with this and that password and it failed (password 
would be redacted). If you use "with generated password", that password will 
not be even shown in audit log. I am not completely sure if the warning is 
logged too if password is not valid (I do think that only CQL command itself is 
audit-logged).

The configuration of validator is in cassandra.yaml. Folks can review that?

I am sorry if I am missing something here, could you expand what you mean?

To Josh:

You are probably right but it is so easy to bypass that it is questionable why 
it is actually there. All it takes is to do "alter role myself with generated 
password" (literally), 5 times in a row and you can set the original one back. 
One positive fact is that such password, even same as the original one, would 
still have to be valid, but it just might be same as it was.


From: Derek Chen-Becker 
mailto:de...@chen-becker.org>>>
Sent: Tuesday, October 11, 2022 17:14
To: 
dev@cassandra.apache.org>
Subject: Re: [Discuss] CEP-24 Password validation and generation

NetApp Security WARNING: This is an external email. Do not click links or open 
attachments unless you recognize the sender and know the content is safe.



On top of what Josh said, a corresponding requirement here would be auditing. A 
password complexity and/or history policy is one piece of security posture, but 
is itself insufficient to be considered "secure". What kind of logs will this 
new policy checker emit that the folks responsible for security for a given 
cluster can parse, process, and report on?

Cheers,

Derek

On Tue, Oct 11, 2022 at 9:07 AM Josh McKenzie 
mailto:jmcken...@apache.org>>

Re: [Discuss] CEP-24 Password validation and generation

[Jeff Jirsa]

I don't think logging which policy violation was triggered is that big of
an ask?

"Password changed for user X, complying with policies (reuse, complexity,
entropy)"
"ERROR: Password rejected due to policy violation (reuse)"
"ERROR: Password rejected due to policy violation (complexity)"
"ERROR: Password rejected due to policy violation (entropy)"

The success log makes it much easier for users subject to audit controls,
and the failures make it much easier to tell users what's going on for
those users who operate the database for other people.




On Tue, Oct 11, 2022 at 11:48 AM Miklosovic, Stefan <
stefan.mikloso...@netapp.com> wrote:

> I am afraid this is way out of scope of this CEP. I think we would be the
> very first on the database scene to offer such low-level and fine-grained
> information. I am not persuaded that this is something we should be giving
> a lot of attention right now. We have "cassandra / cassandra" credentials
> combo as default, I would say that is more important to deal with right now
> than providing very detailed information about what kind of passwords
> people are using.
>
> Thank you very much for (not only your) insights. This is very important
> feedback and I am glad you participate in this thread. I will try to
> summarize where we are as it is easy to get lost in these emails.
>
> 
> From: Derek Chen-Becker 
> Sent: Tuesday, October 11, 2022 18:59
> To: dev@cassandra.apache.org
> Subject: Re: [Discuss] CEP-24 Password validation and generation
>
> NetApp Security WARNING: This is an external email. Do not click links or
> open attachments unless you recognize the sender and know the content is
> safe.
>
>
>
> Speaking with my operator hat on, I would want to know if there's a common
> pattern that my end users hit so that I can better educate them or provide
> tools (e.g. vaults) to help them manage the required complexity.
>
> Cheers,
>
> Derek
>
> On Tue, Oct 11, 2022 at 10:06 AM Miklosovic, Stefan <
> stefan.mikloso...@netapp.com> wrote:
> "but we should consider logging why it was rejected."
>
> Why? What is the use case? Why is it important for you to know what
> somebody tried to create a role with password "aa" (it will not be
> shown), just mentioning that they tried to create a password with a lot of
> repeating characters? What is the added value here?
>
> I need to double check if warnings are logged as well. I'll get back to
> you.
>
>
> 
> From: Derek Chen-Becker  de...@chen-becker.org>>
> Sent: Tuesday, October 11, 2022 17:47
> To: dev@cassandra.apache.org
> Subject: Re: [Discuss] CEP-24 Password validation and generation
>
> NetApp Security WARNING: This is an external email. Do not click links or
> open attachments unless you recognize the sender and know the content is
> safe.
>
>
>
> I know we log that the password change attempt was made, but we should
> consider logging why it was rejected. As part of that, we may want to
> consider how we format that message to make it easy for an auditing system
> to parse. We should never log the actual password, or even a redacted
> version; apologies if it sounded like I was suggesting that.
>
> Cheers,
>
> Derek
>
> On Tue, Oct 11, 2022 at 9:36 AM Miklosovic, Stefan <
> stefan.mikloso...@netapp.com stefan.mikloso...@netapp.com>> wrote:
> I dont follow, sorry. What logs do you mean? What would you like to see?
>
> The auditing framework we already do have in place will log that somebody
> tried to create (or alter) a role with this and that password and it failed
> (password would be redacted). If you use "with generated password", that
> password will not be even shown in audit log. I am not completely sure if
> the warning is logged too if password is not valid (I do think that only
> CQL command itself is audit-logged).
>
> The configuration of validator is in cassandra.yaml. Folks can review that?
>
> I am sorry if I am missing something here, could you expand what you mean?
>
> To Josh:
>
> You are probably right but it is so easy to bypass that it is questionable
> why it is actually there. All it takes is to do "alter role myself with
> generated password" (literally), 5 times in a row and you can set the
> original one back. One positive fact is that such password, even same as
> the original one, would still have to be valid, but it just might be same
> as it was.
>
> 
> From: Derek Chen-Becker  de...@chen-becker.org>>>
> Sent: Tuesday, October 11, 2022 17:14
> To: dev@cassandra.apache.org dev@cassandra.apache.org>
> Subject: Re: [Discuss] CEP-24 Password validation and generation
>
> NetApp Security WARNING: This is

Re: [Discuss] CEP-24 Password validation and generation

[Miklosovic, Stefan]

Hi Jeff,

do you think this is enough? (1) When a user tries to set a password which is 
not valid, it not only rejects such query but it will inform him why it failed.

Do you consider this enough when it comes to quality of information? Do you 
want that to be logged via slf4j logger or where exactly do you want that 
message to appear other than in query result among warnings / errors?

(1) 
https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-24:+Password+validation+and+generation#CEP24:Passwordvalidationandgeneration-Examplesofvalidation


From: Jeff Jirsa 
Sent: Tuesday, October 11, 2022 20:56
To: dev@cassandra.apache.org
Subject: Re: [Discuss] CEP-24 Password validation and generation

NetApp Security WARNING: This is an external email. Do not click links or open 
attachments unless you recognize the sender and know the content is safe.



I don't think logging which policy violation was triggered is that big of an 
ask?

"Password changed for user X, complying with policies (reuse, complexity, 
entropy)"
"ERROR: Password rejected due to policy violation (reuse)"
"ERROR: Password rejected due to policy violation (complexity)"
"ERROR: Password rejected due to policy violation (entropy)"

The success log makes it much easier for users subject to audit controls, and 
the failures make it much easier to tell users what's going on for those users 
who operate the database for other people.




On Tue, Oct 11, 2022 at 11:48 AM Miklosovic, Stefan 
mailto:stefan.mikloso...@netapp.com>> wrote:
I am afraid this is way out of scope of this CEP. I think we would be the very 
first on the database scene to offer such low-level and fine-grained 
information. I am not persuaded that this is something we should be giving a 
lot of attention right now. We have "cassandra / cassandra" credentials combo 
as default, I would say that is more important to deal with right now than 
providing very detailed information about what kind of passwords people are 
using.

Thank you very much for (not only your) insights. This is very important 
feedback and I am glad you participate in this thread. I will try to summarize 
where we are as it is easy to get lost in these emails.


From: Derek Chen-Becker mailto:de...@chen-becker.org>>
Sent: Tuesday, October 11, 2022 18:59
To: dev@cassandra.apache.org
Subject: Re: [Discuss] CEP-24 Password validation and generation

NetApp Security WARNING: This is an external email. Do not click links or open 
attachments unless you recognize the sender and know the content is safe.



Speaking with my operator hat on, I would want to know if there's a common 
pattern that my end users hit so that I can better educate them or provide 
tools (e.g. vaults) to help them manage the required complexity.

Cheers,

Derek

On Tue, Oct 11, 2022 at 10:06 AM Miklosovic, Stefan 
mailto:stefan.mikloso...@netapp.com>>>
 wrote:
"but we should consider logging why it was rejected."

Why? What is the use case? Why is it important for you to know what somebody 
tried to create a role with password "aa" (it will not be shown), just 
mentioning that they tried to create a password with a lot of repeating 
characters? What is the added value here?

I need to double check if warnings are logged as well. I'll get back to you.



From: Derek Chen-Becker 
mailto:de...@chen-becker.org>>>
Sent: Tuesday, October 11, 2022 17:47
To: 
dev@cassandra.apache.org>
Subject: Re: [Discuss] CEP-24 Password validation and generation

NetApp Security WARNING: This is an external email. Do not click links or open 
attachments unless you recognize the sender and know the content is safe.



I know we log that the password change attempt was made, but we should consider 
logging why it was rejected. As part of that, we may want to consider how we 
format that message to make it easy for an auditing system to parse. We should 
never log the actual password, or even a redacted version; apologies if it 
sounded like I was suggesting that.

Cheers,

Derek

On Tue, Oct 11, 2022 at 9:36 AM Miklosovic, Stefan 
mailto:stefan.mikloso...@netapp.com>>

Looking for reviewers for CircleCI config and doc fix

[Derek Chen-Becker]

Hi,

I have a minor doc fix for the CircleCI generate.sh script:

https://github.com/apache/cassandra/pull/1902

@adelapena made the change to the script that added the flag, so maybe he
could take a quick look. On the CircleCI build itself, I have a small PR to
make the offheap dtests run (they're currently missing):

https://github.com/apache/cassandra/pull/1904

Ekaterina was helping with this but it sounds like she's unavailable until
next week, so I was wondering if someone else familiar with CircleCI could
take a look.

Thanks,

Derek


-- 
+---+
| Derek Chen-Becker |
| GPG Key available at https://keybase.io/dchenbecker and   |
| https://pgp.mit.edu/pks/lookup?search=derek%40chen-becker.org |
| Fngrprnt: EB8A 6480 F0A3 C8EB C1E7  7F42 AFC5 AFEE 96E4 6ACC  |
+---+

Re: [Discuss] CEP-24 Password validation and generation

[Derek Chen-Becker]

Thanks Jeff, you put it more succinctly than I was able to. I think just
having these logged out in the app log would be sufficient for audit
purposes.

Cheers,

Derek

On Tue, Oct 11, 2022 at 12:56 PM Jeff Jirsa  wrote:

> I don't think logging which policy violation was triggered is that big of
> an ask?
>
> "Password changed for user X, complying with policies (reuse, complexity,
> entropy)"
> "ERROR: Password rejected due to policy violation (reuse)"
> "ERROR: Password rejected due to policy violation (complexity)"
> "ERROR: Password rejected due to policy violation (entropy)"
>
> The success log makes it much easier for users subject to audit controls,
> and the failures make it much easier to tell users what's going on for
> those users who operate the database for other people.
>
>
>
>
> On Tue, Oct 11, 2022 at 11:48 AM Miklosovic, Stefan <
> stefan.mikloso...@netapp.com> wrote:
>
>> I am afraid this is way out of scope of this CEP. I think we would be the
>> very first on the database scene to offer such low-level and fine-grained
>> information. I am not persuaded that this is something we should be giving
>> a lot of attention right now. We have "cassandra / cassandra" credentials
>> combo as default, I would say that is more important to deal with right now
>> than providing very detailed information about what kind of passwords
>> people are using.
>>
>> Thank you very much for (not only your) insights. This is very important
>> feedback and I am glad you participate in this thread. I will try to
>> summarize where we are as it is easy to get lost in these emails.
>>
>> 
>> From: Derek Chen-Becker 
>> Sent: Tuesday, October 11, 2022 18:59
>> To: dev@cassandra.apache.org
>> Subject: Re: [Discuss] CEP-24 Password validation and generation
>>
>> NetApp Security WARNING: This is an external email. Do not click links or
>> open attachments unless you recognize the sender and know the content is
>> safe.
>>
>>
>>
>> Speaking with my operator hat on, I would want to know if there's a
>> common pattern that my end users hit so that I can better educate them or
>> provide tools (e.g. vaults) to help them manage the required complexity.
>>
>> Cheers,
>>
>> Derek
>>
>> On Tue, Oct 11, 2022 at 10:06 AM Miklosovic, Stefan <
>> stefan.mikloso...@netapp.com> wrote:
>> "but we should consider logging why it was rejected."
>>
>> Why? What is the use case? Why is it important for you to know what
>> somebody tried to create a role with password "aa" (it will not be
>> shown), just mentioning that they tried to create a password with a lot of
>> repeating characters? What is the added value here?
>>
>> I need to double check if warnings are logged as well. I'll get back to
>> you.
>>
>>
>> 
>> From: Derek Chen-Becker > de...@chen-becker.org>>
>> Sent: Tuesday, October 11, 2022 17:47
>> To: dev@cassandra.apache.org
>> Subject: Re: [Discuss] CEP-24 Password validation and generation
>>
>> NetApp Security WARNING: This is an external email. Do not click links or
>> open attachments unless you recognize the sender and know the content is
>> safe.
>>
>>
>>
>> I know we log that the password change attempt was made, but we should
>> consider logging why it was rejected. As part of that, we may want to
>> consider how we format that message to make it easy for an auditing system
>> to parse. We should never log the actual password, or even a redacted
>> version; apologies if it sounded like I was suggesting that.
>>
>> Cheers,
>>
>> Derek
>>
>> On Tue, Oct 11, 2022 at 9:36 AM Miklosovic, Stefan <
>> stefan.mikloso...@netapp.com> stefan.mikloso...@netapp.com>>
>> wrote:
>> I dont follow, sorry. What logs do you mean? What would you like to see?
>>
>> The auditing framework we already do have in place will log that somebody
>> tried to create (or alter) a role with this and that password and it failed
>> (password would be redacted). If you use "with generated password", that
>> password will not be even shown in audit log. I am not completely sure if
>> the warning is logged too if password is not valid (I do think that only
>> CQL command itself is audit-logged).
>>
>> The configuration of validator is in cassandra.yaml. Folks can review
>> that?
>>
>> I am sorry if I am missing something here, could you expand what you mean?
>>
>> To Josh:
>>
>> You are probably right but it is so easy to bypass that it is
>> questionable why it is actually there. All it takes is to do "alter role
>> myself with generated password" (literally), 5 times in a row and you can
>> set the original one back. One positive fact is that such password, even
>> same as the original one, would still have to be valid, but it just might
>> be same as it was.
>>
>> 
>> From: Derek Ch

New episode of The Apache Cassandra Corner(R)

[Aaron Ploetz]

Link to next episode:

Ep10 - Cheng Wang and Jordan West (Netflix)

https://drive.google.com/file/d/1_f-0vTv-ZDZEcLSgqW8b8NQbAjmlQM2Q/view?usp=sharing

(You may have to download it to listen)

It will remain in staging for 72 hours, going live (assuming no objections)
by Friday (night), October 14th.

If anyone should have any questions, comments, or if you want to be a
guest, please reach out to me.

Thanks, everyone!

Aaron