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<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 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<mailto:bscho...@gmail.com>>
Sent: Monday, October 10, 2022 17:43
To: dev@cassandra.apache.org<mailto: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<http://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><mailto: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
