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

[Miklosovic, Stefan]

Thanks Andrés.

After careful consideration, I think it would be better if the initial 
implementation dropped the validation of a password against the previous ones 
so people can not re-use them too often. This feature would bring additional 
complexity and new table in system_auth keyspace. It is good we know how we 
could do that if somebody really wants that to happen. I just do not find it 
absolutely necessary at this time. Simple validation / generation with related 
CQL commands should be enough at the moment and we can expand that as we go.

I will reflect this into the CEP and I will initiate the vote soon. It is 
around 3 weeks since I posted this and that seems to be quite a long time for 
everybody being able to raise their questions if they had any.

This seems to be quite straightforward CEP anyway, I wanted to put everything 
together as that topic is rather broad with all the details involved and CEP 
seemed to be a good way how to cement that.



From: Andrés de la Peña 
Sent: Friday, September 23, 2022 13:36
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 think that custom, pluggable type of guardrail will be a great addition to 
the framework.

The first guardrails prototype included a factory of guardrails that was able 
to provide different guardrail instances depending on the specified class and 
client state. That was discarded during review in favour of a pluggable 
provider of guardrail configurations, so the guardrail instances are always the 
same but the source of configuration can be customized. That allows to provide 
different configurations for different users with minimal hassle. Although that 
works for most of the guardrails, it doesn't give the kind of flexibility than 
the ability to plug custom guardrail implementations does.

I think that the proposed approach for making specific guardrail 
implementations pluggable allows us to keep the simplicity of the current 
approach while also giving us flexibility for particular cases like password 
validation. The generic CustomGuardrail that will be added to the framework 
should ease (and standardize!) validation pluggability, so I think it can be 
useful in the future.

On Mon, 19 Sept 2022 at 12:27, Miklosovic, Stefan 
mailto:stefan.mikloso...@netapp.com>> wrote:
Hi list,

together with my colleague Jackson Fleming we put together CEP-24 about 
password validation and password generation in Cassandra.

https://cwiki.apache.org/confluence/x/QoueDQ

We are looking forward to discuss this CEP with you in depth.

The outcome of this thread would be to sort out any issues / concerns you have 
so we might eventually vote and implement that in upstream if our contribution 
is found to be useful.

There is a reference implementation provided we would like to build our 
solution on top.

Regards

Stefan Miklosovic

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

[Brad]

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 approach - NCSC.GOV.UK


Regards,

Brad


On Mon, Sep 19, 2022 at 7:27 AM Miklosovic, Stefan <
stefan.mikloso...@netapp.com> wrote:

> Hi list,
>
> together with my colleague Jackson Fleming we put together CEP-24 about
> password validation and password generation in Cassandra.
>
> https://cwiki.apache.org/confluence/x/QoueDQ
>
> We are looking forward to discuss this CEP with you in depth.
>
> The outcome of this thread would be to sort out any issues / concerns you
> have so we might eventually vote and implement that in upstream if our
> contribution is found to be useful.
>
> There is a reference implementation provided we would like to build our
> solution on top.
>
> Regards
>
> Stefan Miklosovic
>

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

[Miklosovic, Stefan]

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 approach - 
NCSC.GOV.UK

Regards,

Brad


On Mon, Sep 19, 2022 at 7:27 AM Miklosovic, Stefan 
mailto:stefan.mikloso...@netapp.com>> wrote:
Hi list,

together with my colleague Jackson Fleming we put together CEP-24 about 
password validation and password generation in Cassandra.

https://cwiki.apache.org/confluence/x/QoueDQ

We are looking forward to discuss this CEP with you in depth.

The outcome of this thread would be to sort out any issues / concerns you have 
so we might eventually vote and implement that in upstream if our contribution 
is found to be useful.

There is a reference implementation provided we would like to build our 
solution on top.

Regards

Stefan Miklosovic