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. ‘aaaaaa’, ‘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 <bscho...@gmail.com>
> 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<
> https://pages.nist.gov/800-63-3/sp800-63b.html#memsecretver> and the NCSC
> Password policy: updating your approach - NCSC.GOV.UK<
> https://www.ncsc.gov.uk/collection/passwords/updating-your-approach#PasswordGuidance:UpdatingYourApproach-Don'tenforceregularpasswordexpiry
> >
>
> Regards,
>
> Brad
>
>
> On Mon, Sep 19, 2022 at 7:27 AM Miklosovic, Stefan <
> stefan.mikloso...@netapp.com<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
>
