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

[Fleming, Jackson]

Password Meter - This is an interesting use case, password meters work really 
well when users are using a visual aid (like a website sign up page). I’d be 
concerned by just limiting the complexity that we would require to a single 
number, when a user attempts to create or update a password that’s too weak, 
how do we specify the issue/issues we see with said password?

To an operator saying “A role must have a password that has a strength of 
90/100” doesn’t have much meaning outside of it’s probably a strong password. 
This makes meeting organisational password requirements near impossible, which 
I would argue is the key use case we are trying to satisfy.

Most organisations I’ve been in have very prescriptive password policies, ‘a 
password must be a minimum n characters long’, ‘must have so many special 
characters’ etc (I am sure most people in this mailing list have had the same 
experience). A meter circumvents this in some regards, while in practice a 
password that does not meet an arbitrary length and set of composition rules 
could be stronger than a password that does meet that set of rules, I can see 
problems trying to get this setup in organisations where these kinds of strict 
rules exists, since to an IT Security team/department the number that a meter 
outputs would be fairly subjective/arbitrary (even though the algorithm to 
generate that score would be in the public domain).

While I agree we should align as closely to NIST as possible, we shouldn’t be 
restricted by it, given the requirement is SHOULD and not SHALL (per the 
verbiage outlined under Requirements Notation and Conventions). I would be 
extremely interested in seeing an implementation that implements a password 
meter that also covers these problems, I think that the current approach is 
more implementable and more palatable to operators and organisations that want 
to use Cassandra.

Regards,

Jackson

From: Brad 
Date: Wednesday, 12 October 2022 at 2:42 am
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 descripti

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

[Fleming, Jackson]

I agree that any password change (or attempted change) would be very important 
audit data that would need to be captured, I don’t think that auditors would 
necessarily need to know the reason for rejection for a validator? Maybe I’ve 
just worked within less strict auditing requirements though.

We probably need to ensure that any logging is distinct enough for auditing 
purposes (so a password policy violation isn’t confused with say a user lacking 
permission to perform the operation they attempted).

I would note that for telling users about why their password changes were 
rejected, a message is sent back to them detailing why the password was 
rejected is part of this CEP. For example:

InvalidRequest: Error from server: code=2200 [Invalid query] message="Guardrail 
password violated: Password was not set as it violated configured password 
strength policy. To resolve this error, the following has to be done: Password 
must be 8 or more characters in length. "

Cheers,

Jackson


From: Derek Chen-Becker 
Date: Wednesday, 12 October 2022 at 7:07 am
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.


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 
mailto:jji...@gmail.com>> 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 
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 i

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

[Brad]

Jackson,

You make a good case for implementing a solution that works with existing
policies vs perhaps better but less common practices.

There was a OSS password complexity meter in the OWASP Enterprise Security
API (ESAPI) Java toolkit in ESAPI 2.x.  It was a pass/fail meter testing
for complexity and throwing an exception "New password is not long and
complex enough" for invalid passwords. ESAI seems to have died as a project
after 2.x.

 see verifyPasswordStrength() in:

https://github.com/ESAPI/esapi-java-legacy/blob/develop/src/main/java/org/owasp/esapi/reference/FileBasedAuthenticator.java

Regards,

Brad

On Wed, Oct 12, 2022 at 4:16 AM Fleming, Jackson 
wrote:

> Password Meter - This is an interesting use case, password meters work
> really well when users are using a visual aid (like a website sign up
> page). I’d be concerned by just limiting the complexity that we would
> require to a single number, when a user attempts to create or update a
> password that’s too weak, how do we specify the issue/issues we see with
> said password?
>
>
>
> To an operator saying “A role must have a password that has a strength of
> 90/100” doesn’t have much meaning outside of it’s probably a strong
> password. This makes meeting organisational password requirements near
> impossible, which I would argue is the key use case we are trying to
> satisfy.
>
>
>
> Most organisations I’ve been in have very prescriptive password policies,
> ‘a password must be a minimum n characters long’, ‘must have so many
> special characters’ etc (I am sure most people in this mailing list have
> had the same experience). A meter circumvents this in some regards, while
> in practice a password that does not meet an arbitrary length and set of
> composition rules could be stronger than a password that does meet that set
> of rules, I can see problems trying to get this setup in organisations
> where these kinds of strict rules exists, since to an IT Security
> team/department the number that a meter outputs would be fairly
> subjective/arbitrary (even though the algorithm to generate that score
> would be in the public domain).
>
>
>
> While I agree we should align as closely to NIST as possible, we shouldn’t
> be restricted by it, given the requirement is SHOULD and not SHALL (per the
> verbiage outlined under Requirements Notation and Conventions). I would be
> extremely interested in seeing an implementation that implements a password
> meter that also covers these problems, I think that the current approach is
> more implementable and more palatable to operators and organisations that
> want to use Cassandra.
>
>
>
> Regards,
>
>
>
> Jackson
>
>
>
> *From: *Brad 
> *Date: *Wednesday, 12 October 2022 at 2:42 am
> *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 <
> 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 

Re: [RELEASE] Apache Cassandra 4.1-beta1 released

[Mick Semb Wever]

Correction…


Downloads of source and binary distributions are listed in our download
> section:
>
>  http://cassandra.apache.org/download/
>


The source and binary distributions are to be found here:
https://downloads.apache.org/cassandra/4.1-beta1/

(4.1 won't appear on our downloads page until it reaches RC)