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 <jackson.flem...@netapp.com>
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 <bscho...@gmail.com>
> *Date: *Wednesday, 12 October 2022 at 2:42 am
> *To: *dev@cassandra.apache.org <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 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
>
>
