Thanks Jeff, you put it more succinctly than I was able to. I think just having these logged out in the app log would be sufficient for audit purposes.
Cheers, Derek On Tue, Oct 11, 2022 at 12:56 PM Jeff Jirsa <jji...@gmail.com> wrote: > I don't think logging which policy violation was triggered is that big of > an ask? > > "Password changed for user X, complying with policies (reuse, complexity, > entropy)" > "ERROR: Password rejected due to policy violation (reuse)" > "ERROR: Password rejected due to policy violation (complexity)" > "ERROR: Password rejected due to policy violation (entropy)" > > The success log makes it much easier for users subject to audit controls, > and the failures make it much easier to tell users what's going on for > those users who operate the database for other people. > > > > > On Tue, Oct 11, 2022 at 11:48 AM Miklosovic, Stefan < > stefan.mikloso...@netapp.com> wrote: > >> I am afraid this is way out of scope of this CEP. I think we would be the >> very first on the database scene to offer such low-level and fine-grained >> information. I am not persuaded that this is something we should be giving >> a lot of attention right now. We have "cassandra / cassandra" credentials >> combo as default, I would say that is more important to deal with right now >> than providing very detailed information about what kind of passwords >> people are using. >> >> Thank you very much for (not only your) insights. This is very important >> feedback and I am glad you participate in this thread. I will try to >> summarize where we are as it is easy to get lost in these emails. >> >> ________________________________________ >> From: Derek Chen-Becker <de...@chen-becker.org> >> Sent: Tuesday, October 11, 2022 18:59 >> 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. >> >> >> >> 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<mailto: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<mailto: >> de...@chen-becker.org>> >> Sent: Tuesday, October 11, 2022 17:47 >> 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 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><mailto: >> 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><mailto: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><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. >> >> >> >> 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>><mailto: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>><mailto: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>><mailto: >> 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><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>>><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<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 | >> +---------------------------------------------------------------+ >> >> -- +---------------------------------------------------------------+ | 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 | +---------------------------------------------------------------+
