New episode of The Apache Cassandra Corner(R)

2022-10-11 Thread 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

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

2022-10-11 Thread 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

Looking for reviewers for CircleCI config and doc fix

2022-10-11 Thread 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

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

2022-10-11 Thread 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

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

2022-10-11 Thread 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:

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

2022-10-11 Thread 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"

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

2022-10-11 Thread 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 >

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

2022-10-11 Thread 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 <

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

2022-10-11 Thread 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?

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

2022-10-11 Thread 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’,

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

2022-10-11 Thread 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;

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

2022-10-11 Thread 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

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

2022-10-11 Thread 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

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

2022-10-11 Thread 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

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

2022-10-11 Thread 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,

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

2022-10-11 Thread 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: > >

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

2022-10-11 Thread 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 ( >

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

2022-10-11 Thread 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

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

2022-10-11 Thread 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 ( >>

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

2022-10-11 Thread 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