> 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, but this strikes me as in the "we can only do so much to prevent people from doing stupid things" category. If someone's so hell-bent on circumventing their company's attempts at security they're probably much more at risk of running unidentified attachments or giving out credentials over the phone rather than finding clever ways to work around annoying password rotation rules on their db accounts right?
On Mon, Oct 10, 2022, at 4:08 PM, Miklosovic, Stefan 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 >
