Speaking with my operator hat on, I would want to know if there's a common pattern that my end users hit so that I can better educate them or provide tools (e.g. vaults) to help them manage the required complexity.
Cheers, Derek On Tue, Oct 11, 2022 at 10:06 AM Miklosovic, Stefan < stefan.mikloso...@netapp.com> wrote: > "but we should consider logging why it was rejected." > > Why? What is the use case? Why is it important for you to know what > somebody tried to create a role with password "aaaaaaaaaa" (it will not be > shown), just mentioning that they tried to create a password with a lot of > repeating characters? What is the added value here? > > I need to double check if warnings are logged as well. I'll get back to > you. > > > ________________________________________ > From: Derek Chen-Becker <de...@chen-becker.org> > Sent: Tuesday, October 11, 2022 17:47 > 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 know we log that the password change attempt was made, but we should > consider logging why it was rejected. As part of that, we may want to > consider how we format that message to make it easy for an auditing system > to parse. We should never log the actual password, or even a redacted > version; apologies if it sounded like I was suggesting that. > > Cheers, > > Derek > > On Tue, Oct 11, 2022 at 9:36 AM Miklosovic, Stefan < > stefan.mikloso...@netapp.com<mailto:stefan.mikloso...@netapp.com>> wrote: > I dont follow, sorry. What logs do you mean? What would you like to see? > > The auditing framework we already do have in place will log that somebody > tried to create (or alter) a role with this and that password and it failed > (password would be redacted). If you use "with generated password", that > password will not be even shown in audit log. I am not completely sure if > the warning is logged too if password is not valid (I do think that only > CQL command itself is audit-logged). > > The configuration of validator is in cassandra.yaml. Folks can review that? > > I am sorry if I am missing something here, could you expand what you mean? > > To Josh: > > You are probably right but it is so easy to bypass that it is questionable > why it is actually there. All it takes is to do "alter role myself with > generated password" (literally), 5 times in a row and you can set the > original one back. One positive fact is that such password, even same as > the original one, would still have to be valid, but it just might be same > as it was. > > ________________________________________ > From: Derek Chen-Becker <de...@chen-becker.org<mailto: > de...@chen-becker.org>> > Sent: Tuesday, October 11, 2022 17:14 > 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. > > > > On top of what Josh said, a corresponding requirement here would be > auditing. A password complexity and/or history policy is one piece of > security posture, but is itself insufficient to be considered "secure". > What kind of logs will this new policy checker emit that the folks > responsible for security for a given cluster can parse, process, and report > on? > > Cheers, > > Derek > > On Tue, Oct 11, 2022 at 9:07 AM Josh McKenzie <jmcken...@apache.org > <mailto:jmcken...@apache.org><mailto:jmcken...@apache.org<mailto: > jmcken...@apache.org>>> wrote: > 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<mailto:bscho...@gmail.com><mailto: > bscho...@gmail.com<mailto:bscho...@gmail.com>>> > Sent: Monday, October 10, 2022 17:43 > To: dev@cassandra.apache.org<mailto:dev@cassandra.apache.org><mailto: > 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>< > 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>><mailto: > 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 > > > > > -- > +---------------------------------------------------------------+ > | Derek Chen-Becker | > | GPG Key available at https://keybase.io/dchenbecker and | > | https://pgp.mit.edu/pks/lookup?search=derek%40chen-becker.org | > | Fngrprnt: EB8A 6480 F0A3 C8EB C1E7 7F42 AFC5 AFEE 96E4 6ACC | > +---------------------------------------------------------------+ > > > > -- > +---------------------------------------------------------------+ > | Derek Chen-Becker | > | GPG Key available at https://keybase.io/dchenbecker and | > | https://pgp.mit.edu/pks/lookup?search=derek%40chen-becker.org | > | Fngrprnt: EB8A 6480 F0A3 C8EB C1E7 7F42 AFC5 AFEE 96E4 6ACC | > +---------------------------------------------------------------+ > > -- +---------------------------------------------------------------+ | Derek Chen-Becker | | GPG Key available at https://keybase.io/dchenbecker and | | https://pgp.mit.edu/pks/lookup?search=derek%40chen-becker.org | | Fngrprnt: EB8A 6480 F0A3 C8EB C1E7 7F42 AFC5 AFEE 96E4 6ACC | +---------------------------------------------------------------+
